Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I am sick and tired of hearing tech companies complain about developer shortages

blog.usejournal.com

Post reply on HN
Print view View original

571–580 of 583 posts

Re: I am sick and tired of hearing tech companies complain about developer shortages

#571

Post by dorgo »

readonthegoapp wrote: post #563
dorgo wrote: post #552

Earlier quoted context omitted.

It depends. x = {} + 12; x has the value "[object Object]12". So, it' not always 12 :P

can confirm: https://replit.com/@atlwellwell/EsotericJSInterviewQuestion#... at this point, i'd love to know when the answer is just '12'. i remember going at it with some dude back in the day who was 100% certain, and got visibly upset, when i stood my ground that java only used pass by value. i allowed that even object references were being passed, but that they were passed by value. i didn't get the job.

>at this point, i'd love to know when the answer is just '12'.

Ctrl+Shift+k in a browser (firefox) opens a console. Just write {}+12 there and hit enter.

My guess is that {} is (in some circumstances) evaluated as a block of code (instead of an empty object). Since the block is empty it evaluates to undefined. The +12 is considered another block of code ( the + operation takes here only one parameter - so it is not a sum ). Consecutive blocks of code are evaluated to the value of the last block of code, which is +12.

{}/12 for example doesn't work at all - which is a hint that the + is not a summation operation.

Edit: I'm wondering why we use 12 and not 42

Edit2: Technically you are correct about java being pass by value. But at this point I'm questioning the sanity of the distinction. It feels more and more like a philosophical discussion.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#572

Post by flippinburgers »

nasalgoat wrote: post #470
ditonal wrote: post #182

Earlier quoted context omitted.

It's basically both. When I graduated with my CS degree, I was _thrilled_ to be offered 50k. Now new grads feel lowballed at 200k TC. So hard not to say that the market hasn't adjusted somewhat. At the same time, part of the reason companies even have to pay so much is because they've made interviewing so damn hard. I personally know many people at great companies like Google and Twitter who are _desperate_ to change…

I spent nearly a year interviewing at various companies and never landing a job despite decades of practical, relevant experience. It was extremely demoralizing and worrisome, and I believe the majority of the issue was extremely difficult interview processes. The size of the company didn't matter - in fact, the smaller the company, the more difficult and onerous the process was. One place with six employees asked fo…

Sometimes I wonder if small companies are just full of bitter google rejects who have decided to make the interview process miserable to boost their own egos. I went through a year of being unemployed not too long ago and it was very painful. Receiving no feedback is the worst part by far.

A recent project required some work in jquery. All of the other developers stated that it would be difficult and take them too long because they were not familiar with it - being react devs themselves - so it was left to me. I was shocked. The idea that jquery could possibly be described as being more difficult than react is amusing at best. Sure, it was largely an excuse on their part, but I was left speechless nonetheless.

I guess my point is that nearly 20 years of dev experience leaves me with the ability to do the old and the new. I wish this was more respected by companies in general.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#573

Post by flippinburgers »

Tossrock wrote: post #20

> The general rudeness is ridiculous. I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up. > This experience is fairly common. Is it? I've done a fair bit of interviewing on both sides of the table, and can say with complete honesty I've never heard a curse said in anger in any of them. I…

I have heard co-workers curse, myself included.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#574

Post by amluto »

pkolaczk wrote: post #234
amluto wrote: post #140

Earlier quoted context omitted.

> But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies It’s not just performance. In any moderately complicated C++ program, you will want a function to mutate its argument, and this falls apart. Sure, you can write in a pure functional style with immutable data structures, but I wish you luck implementing an immutable data structure with asymptotically reasonable perform…

Unfortunately many programmers underestimate the speed at which computers can copy flat regions of memory these days and overestimate speed of code littered with pointers and indirection. Often using pointers to avoid copying a few bytes leads to worse performance. In my experience a combination of pass-by-value with move semantics provides good code readability and almost optimal performance in most cases, so that's…

> copy flat regions

A map or pretty much any nontrivial data structure is not a flat region.

In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game takes ten minutes to load.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#575

Post by amluto »

rightbyte wrote: post #507
amluto wrote: post #132

Earlier quoted context omitted.

And footguns that an experienced person might hit. One family of such footguns is: const auto &foo = something(args); … other_thing(foo); Depending on exactly what you’re doing and what type something(args) returns, this can be entirely correct and idiomatic. In other circumstances it accesses a reference after its lifetime. One can debate whether the const belongs there and how many &’s to use, but, unless something…

The temporary's reference is valid until the temporary is destroyed by falling out of scope, swapped etc. Or have I missed something?

The reference itself is indeed valid, in the sense of existing, until it falls out of scope. But the object it references may not be, so using the reference can be UB. Consider an std::vector v with length known to be at least 1:

    const auto &ref = v[0];
    v.push_back(42);
    cout
That works fine until push_back reallocates out of place, at which point you may start to notice that it’s actually UB.

Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.

(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)

Re: I am sick and tired of hearing tech companies complain about developer shortages

#576

Post by pkolaczk »

amluto wrote: post #574
pkolaczk wrote: post #234

Earlier quoted context omitted.

Unfortunately many programmers underestimate the speed at which computers can copy flat regions of memory these days and overestimate speed of code littered with pointers and indirection. Often using pointers to avoid copying a few bytes leads to worse performance. In my experience a combination of pass-by-value with move semantics provides good code readability and almost optimal performance in most cases, so that's…

> copy flat regions A map or pretty much any nontrivial data structure is not a flat region. In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game t…

> A map or pretty much any nontrivial data structure is not a flat region.

Not necessarily. A hashmap can be implemented in a way it stores both the keys and values in a flat memory region, as long as keys and values are fixed size, and such a structure is way more efficient that traditional array-of-pointers implementation, where fetching each key requires following a pointer and getting the value requires following another pointer.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#577

Post by josephg »

jnxx wrote: post #568
josephg wrote: post #397

Earlier quoted context omitted.

> At the same time, part of the reason companies even have to pay so much is because they've made interviewing so damn hard. I don't agree at all. Pre pandemic I worked as a professional software engineering interviewer for a largish recruiting company. I did 400+ ~2hr interviews over about a year. We did not put forward the vast majority of people I interviewed. Lots of people on HN, and certainly lots of people who…

So, assuming this is all essentially right from the employers point of view, what can senior developers do to make the selection / hiring process more efficient for themselves? The thing is that there are a lot of spammy recruiters as well. And dealing with them costs a lot of time. At least if one does not want to do a shotgun approach to applications, one has to be really selective on where to apply, with very litt…

I don't think spending so long on the other side of the fence has given me much special wisdom, but the first thing to mention is that, if you don't have a warm lead, you will need to take the time to prove to the company you're applying to that you have actual programming skills. Nobody wants to waste time doing this; but companies have very few reliable signals outside of an interview to differentiate you from someone who's vaguely terrible at programming. And programming job ads get flooded with low value candidates. They can't tell you apart from your resume (people lie) or your github profile (Its easy to clone semi-popular projects to pad out github repos).

> be selective where to apply

100%. And talk to your friends and get warm leads when you can. You can learn much more about what its like to work at a company by talking to people who already work there. Go in for lunch. Get a sense of the company culture. If you have skill, everyone is hiring. Ignore the recruiters and choose where you want to work.

> do not apply to job descriptions which are not at least a n 80% match with the own qualifications and interests

I disagree with this actually. Again, if you're a senior developer with skills, figure out what the company is doing and decide for yourself if you want to be part of that. Technology match matters here; but job ads are pretty uniformly terrible. Nobody knows how to write them well. I certainly don't.

> architecture and design decisions become much more important for actual senior work

Yes; from the people I interviewed, I found senior developers were competent but still a bit slower than mids at raw programming tasks. (This makes sense, because they often don't do it as much). In comparison, senior devs were much better at debugging problems and at architecture whiteboarding style questions.

> And, another question, how should one handle recruiters and interviewers which apparently have not read the resume?

The first thing to know about recruiters is they don't work for you, because you don't pay them. The way recruiting should work is like acting - you get a manager (recruiter) who knows your skillset well. They talk to lots of companies and find you a stream of good gigs you like. You pay them $10k for that service, or 2% of your salary or something. But programmers hate paying for this, so instead all the recruiters work for the companies. They get the same cut, but our experience of working with them is awful.

I'd avoid most recruiters whenever you can. Use HN's job board and things like that, and skip to talking to the actual team managers and engineers as quickly as possible. Recruiters hunting C++ devs for C# roles is just lazy people being lazy.

And who cares if your interviewer has read your resume? Its disrespectful, but it doesn't matter. Roll with it.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#578

Post by amluto »

pkolaczk wrote: post #576
amluto wrote: post #574

Earlier quoted context omitted.

> copy flat regions A map or pretty much any nontrivial data structure is not a flat region. In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game t…

> A map or pretty much any nontrivial data structure is not a flat region. Not necessarily. A hashmap can be implemented in a way it stores both the keys and values in a flat memory region, as long as keys and values are fixed size, and such a structure is way more efficient that traditional array-of-pointers implementation, where fetching each key requires following a pointer and getting the value requires following…

The resulting code will still be asymptotically slow.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#579

Post by mannerheim »

lazyasciiart wrote: post #561
mannerheim wrote: post #350

Earlier quoted context omitted.

In economic terms, there is no shortage. There's a shortage in common parlance terms, sure. There is an easy solution - pay market rates. When people say there's a shortage of engineers, they mean there's a shortage of engineers at the price they're willing to pay.

Yes. And when people say there is a shortage of food, they mean "at the price they are willing to pay". But new engineers and new foodstuffs will not spring into existence when you add a zero to the price - therefore there is a shortage. You might want to say but oh, more people will become engineers if salaries are higher! But that doesn't ship products this summer.

There are often real food shortages because of price ceilings. Actual food shortages can be seen when the shelves are empty and food cannot be bought at any price.

Re: I am sick and tired of hearing tech companies complain about developer shortages

#580

Post by wreath »

ergocoder wrote: post #522
wreath wrote: post #430

Earlier quoted context omitted.

There is a lot more to software engineering than solving algorithmic problems in a vacuum with little resemblance to real life engineering.

What you say is an empty statement because it doesn't rank which skills are the most important to a software engineer. Coding is the core skill of software engineering. For other skills, say, communication, you will need to have an adequate amount of it, but you don't need to be godlike (e.g. think Bill Clinton's level). If you have the Bill Clinton's level of communication, you will likely be in other positions. Now…

I agree that coding is the core skill of software engineering, no question about that. What I don't agree with is when we make it as a deciding factor in interviews for mid and senior levels. At such stage, I'd assume someone who worked for few employers already know how to code and there are different standards of skills we need to hold them for, such as designing relatively complex systems and understanding tradeoffs, communicating these trade offs, how they deal with priorities to ship a functioning software etc etc. I think we should limit the algorithm problems in an interview to either college graduates/engineers entering the field, or that's an essential part of the job (unlike most Web development)
Post reply on HN