38 comments

[ 3.0 ms ] story [ 91.1 ms ] thread
For those unaware, "All You Zombies..." is a fantastic short story by Robert Heinlein about time travel that was adapted into the 2014 film Predestination (fairly well, too, considering the source material.)
It'd be nice to see a decent Heinlein movie adaptation for a change. Sorry I missed it when it came out.
Yep, the Spierig Brothers are awesome at these kinds of films. I loved their work with Daybreakers.
Watching some managers fail just feels like karma sometimes. I can't imagine the company in question will be around for too long.
> a firm that started out as a telco but morphed into a business service provider

I was thinking this might be AT&T - I've run into a bunch of businesses that have outsourced their IT to AT&T's global services division. Although AT&T is still very much a telco.

(comment deleted)
We've all been there, recruiters calling you because you are the perfect applicant because of your skill with framework XYZ (even though you've never worked with it, nor claimed you have experience with it). And also because of your experience in Java (even though you are a javascript dev). They have the perfect job 'opportunity' for you! As long as you have at least 15 years experience in React and Angular and SCRUM and agile you should be fine. Oh, and you have to lower your hourly rate so the recruiter can make $20+ per hour of of your work.

Seriously, when does it stop?

when someone disrupts recruiting enough to make all that wasted energy uncompetitive.
I don't know, maybe I have been lucky, but I don't get that so much. I get very infrequent recruiter contact, but when they do contact me, they seem to have at least done a little homework. Usually they have the domain/technologies right, and they have made an effort to match skills with the role. My biggest complaint is that once in a while they get the job level way wrong. I've got nearly 20 years under my belt, and I still get approached for individual contributor "seventh engineer from the left" type roles. But that's not a huge deal, just politely decline. I also get a lot of "I see you are doing $ROLE at $COMPANY_1. How would you like to do the exact same $ROLE at $COMPANY_2?" which are not interesting to me but how are they supposed to know that?

I've never been called or harassed by a recruiter, and I try to get back to every one, if only for politeness sake. No reason to burn bridges. If they got the match a little wrong, no big deal--they're not wizards and mind readers.

Do you have LinkedIn? I'm considering ditching it because I'm so sick of recruiter spam and that seems to be their main avenue of contact.
I did it when Microsoft bought them. Not because of it, it was just the moment when I realized that nothing good ever came out via LinkedIn.

Github and Stackoverflow supplied me with all of my decent leads and networking necessary in the past years. For the only two exceptions of people that expected me to have an account there, I told them I could send an up-to-date CV with references, if needed.

Yea, that's pretty much the only channel through which recruiters contact me. Nobody cold-calls or E-mails anymore, and I don't post my resume anywhere.
It depends a lot on what job-searching sites you use and what information you give them. I got on Dice to apply for a particular job, and had to take my phone number off my account there to get the pushy recruiter calls to stop. LinkedIn mostly isn't too bad, but I still wouldn't put a phone number on there.

It's not the type of roles that gets irritating, but the pushiness and desperation of some recruiters. Like they've read too many books on sales and think that they can get any engineer into any job if only they say the right words and are persistent enough.

It stops when you delete your LinkedIn account. Seriously - I get no headhunter spam anymore. Recruiters only call when someone I know makes an internal referral, and I don't mind that.
HR at most companies is filled with people who are too terrible at anything else, so they get shoved into HR. This situation above (at a telecom turned business service provider) is a very common problem -- especially at companies with a large consumer-facing presence.

Because these companies need to hire large volumes of low-skilled workers, they implement rigid HR policies and procedures to streamline the process. Those workers make up probably 95% of their hiring volume -- turnover is high and there are tons of positions available.

These companies fall flat on their fucking face when they try to hire skilled workers. The same processes that make them efficient and streamlined at hiring call center reps make them fucking terrible at skilled labor hiring. They use low-skilled HR reps with zero domain knowledge to filter stuff, then HR always has to be involved in the process "because policy". End result is it takes 4 months to get a resume, interview and extend an offer to someone -- in which time, the best candidates already have started other jobs.

Meanwhile, the engineering groups need to get things done. So when Accenture comes in and says "We can get you a whole team of 50 people in India. And they can start next week." it's hard to say no. And most of the full-time people working at the company are ex-consultants themselves (because that's the only way to actually work at a lot of these companies).

Consultants are basically "shadow HR" at a lot of companies. They wouldn't be so prevalent if these companies were competent at hiring people with relevant skill.

The other side of the problem is the skill level needed to be a good developer.
Oh, I'm not even talking about problems identifying good developers -- even if they find them, HR is so slow and rigid in their process that things like salary negotiations take months, in which time even mediocre candidates have usually found something better.

Basically, HR runs the hiring process at most of these companies, and from HR's perspective the engineering teams are like that annoying customer that keeps complaining because they are a "special flower" (HR detests special flowers). They don't even know what engineering does; just that they have 55 call center positions and 2 engineering positions they need to fill this month.

Not every company is this way, but many big ones are. Specifically the ones where like 70% of the company is consultants.

You must work where I do - all of this sounds familiar.
I have a difficult time understanding how Accenture is still in business but your scenario makes sense.

Having worked a large (billion dollar scale) project with Accenture, I have seen what a mixed bag they can be.

They brought on some absolute rock-star developers and some who probably did more harm to the project than good but none of them had skills that weren't available with domestic talent. I suppose the shackles of H1B visas helped to keep labor costs down.

Yep. This is my experience also with Wipro: one very highly skilled consultant covering for five to ten let's say much more tepid bodies. This racket works well as long as no-one is looking close also middle-managers like to show off roomfulls of people under their notional command.
In the business we call this "leverage". The whole business is a pyramid of lower skilled workers billing high rates while the "talent" works at a loss and does all of the actual work.

You drum out the ones who can't hack it after a year or two and replace them with fresh grads, and you promote and pay the good ones to keep up the charade.

And you're spot on about the middle manager thing. That way they can say "I was over 4 teams with 75 heads so I'm ready to be a VP!" when really all they did was approve expense reports and head-nod to everything I told them. Of course, making sure that middle manager gets promoted is also part of the job -- when he gets promoted, he gets a bigger budget. :)

Then it looks to me that there is no problem.
> "We don't want to train someone," the interveiwer said

That attitude is pervasive, yet seldom expressed so clearly.

And yet, the someone will likely end up training them, if they would only make the hire.
I was waiting for the part where Teddy has to f* his/her past self.
> How would you compare three sets of numbers to see if any number was common to all three?

Ahm ... I would probably just naively brute force loop over the sets, because modern CPUs are insanely fast and I am filthy lazy. And if there is a performance problem I super lazily look up the filtering methods of the language-library.

What would the correct answer here be? Make a hash or something for constant lookup cost?

If it's already a set in the language, use intersect. If the numbers are in a array or sth. similiar, make a set and use intersect. https://en.wikipedia.org/wiki/Intersection_(set_theory)
We here at Company X believe that math is not useful unless it is bespoke, hand-made, artisanal. Please pretend that set theory does not yet exist in this universe, and describe to us the smell of the algorithm you might write to solve this problem.
You just described the "what", not the "how". The implied context is algorithmic. It'd be like answering a question about sorting lists with "use sort()" - true enough in practical terms, but smart-arsey and deliberately avoiding the meat of the question.
Assuming whatever language I'm using has an honest implementation of a set data structure and that these sets of numbers are true sets, and thus, contain no duplicate values; I would perform an intersection.

With Python(my bread and butter), I would simply use the built in intersection set class method: https://docs.python.org/3/library/stdtypes.html?highlight=se...

If the language has a set data structure available, intersect all 3 sets. If it doesn't, sort all three arrays and iteratively go past the smallest value in each array until you arrive at the same value in each array.
Wouldn't that have O(n*logn) time at worst: sorting [O(nlogn)] + traversal [O(n)] ?

If space complexity is not a requirement, wouldn't it be better to iterate over each list and keep track of the occurrences of a digit in a dictionary (whichever keys have 3 occurrences are thus shared)?

That way you could get the value in O(n) time. Or is there something I'm missing?

Iterating each list is at least O(n) (because you just visited each item). So your dictionary building is in itself O(nlogn). As a minor optimization, when you walk the last list you can build the final list incrementally (check for things with two existing visits).
> What would the correct answer here be?

"How many times is this going to run? Is it going to be cheaper to do any naive thing and move on to the next ticket, or should I take the time to actually optimize this?"

That's usually the correct answer, and one I never see in interviews (either asked or offered).