Most normal developers. Spending you time on leetcode means you want to get in a faang. Most people are going for other roles.
While I'm currently not working (for money, anyway) I'm fortunate to be in a position to not have to look for work. That could change, of course (for example, if the SCOTUS strikes down the ACA I'll need to find a job with insurance). Just thinking about interviewing in this current environment makes my stomach tie up in knots. But for now, I'll be over here working on my own interesting problems.
Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly. But we judge candidates on it.
Not only that - I often see atrocious code. Stuff like comparing boolean expressions against true/false. Stuff that makes me question basic competence of the person writing it.
I do this sometimes if it makes the code clearer. Sometimes it's not 100% clear if you're just coming in that a function returns a boolean. Sometimes you just want to remind yourself and it sneaks past a code review. I've been coding for 20 years across a dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript). Sometimes null is false, sometimes it's not, sometimes an empty string is false, sometimes it's not.
Any compiler, JIT, optimizer etc. will completely ignore the comparison anyways so there's 0 runtime issue with it.
I'd argue the function isn't named appropriately, then.
> Sometimes you just want to remind yourself and it sneaks past a code review
Remind yourself what, exactly?
> dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript)
I'd argue that it's on the developer to know and work with the language's semantics (and I say this as someone who's not a fan of JS). Trying to write code that is nearly language agnostic in semantics will leave out a whole lot of language-specific value.
Maybe yes, maybe no. The point is that adding "== true" makes it more clear and should therefore be done.
As do I, the above poster is just super judgemental and probably not a lot of fun to work with.
An observation I've had over the years is that often times developers will come to conclusions that they ought not to. The idea that typing out "== false" indicates you don't understand bools is a non-sequitur.
if not (x > 5)
if (x > 5) == false { .. ]
Why would it matter if a function returned a boolean? It's either compared for truthiness, or the comparison for truthiness or compared for truthiness, even in the most dynamic languages.
Functions are not always consistent about returning a Boolean either. Bad design/naming, but you work with what you have got.
I think some classes were not mandatory in school, or people hated that class.
I will sometimes compare against true/false, it doesn't mean I don't understand boolean logic, it means I feel like it's more clear.
It could also be that I'm in a language with truthy values and I specifically only want to compare to real boolean values.
You really need to stop and ask yourself why you're so judgemental about code. Because that's a you problem, not a them problem.
If I ever had a co-worker try and tell me I don't understand boolean logic because I felt like typing it out was more clear I'd laugh in their face.
It’s visual noise. This isn’t an issue with truthiness either. I’m talking normal java code. Where if I see an if-statement, clearly the thing inside doesn’t need comparison against true or false unless you want to add another comparison just for fun and mental gymnastics.
Are you young or early in your career? I think the extra verbosity is something you come to appreciate the “the hard way” over the years.
There's cases where this might make sense (when things like truthiness are unclear). But in any of the cases I've seen, it's where things are pretty obvious and even when things are explicitly boolean types.
Write the boolean expression and if it doesn't fit or has lots of parts, define them separately above the conditional with clear names.
People seem upset by this, but idk it seems like common sense.
I'm not sure I understand how `if (someCondition == true) {...}` is preferable to `if (someCondition) {...}`
Idk this is just my experience with disorganized code and unclear.
No one is upset, they simply disagree with you...
Maybe avoid trying to dismiss people and look at what they're actually saying? There are things you put in code that others are unfairly judging you for.
something something glass houses.
Response 1: I thought it would be clearer with the explicit comparison. (fine, then you can bring in your own opinion and maybe have a nice discussion)
Response 2: You don't need == true? I never knew. (bad)
Another common scenario that is complained about: using `this` with instance variables when it's technically unnecessary.
if ((conditional == true) == true)
A lot of it is just them not really interviewing much so they Google how to interview developers and think about questions they were asked.
Start with your observation.
I was honestly taken a back. These companies aren’t known for “high” standards and make up for the lack of interesting work with WLB (or at least it comes across like that.
Just like how everyone copied google Qs a decade ago (how many toothpicks can a tree yield...). I’m fully expecting everyone to copy FAANG like interviews because someone in HR thinks it might signal better hires, and why wouldn’t you want better hires right?
Companies that wouldn't have leetcoded you 5, 10, years ago are now doing so. The difficulty of leetcode questions is going up too.
Also, takehome problems are becoming more common - not instead of leetcode interviews, but in addition to.
Examples: run length encoding problem or a bit extracting/setting question. I want to see if the candidate can formulate a simple state machine and they understand bit manipulation. I target the bit manipulation questions for firmware/embedded software roles, which very much involves reading and setting bits from hardware registers all day long.
If the interview is the same, you are better off working at some one who pays better. As a side effect eventually there could across the board better pay.