Live data from Hacker News

The rise of never-ending job interviews

bbc.com

961–970 of 1001 posts

Re: The rise of never-ending job interviews

#961
post #752
post #438

Earlier quoted context omitted.

Just check the Android code, specially the early versions looked like "C dev (not even C++) tries to create a Java based framework". And the NDK clearly is anything but modern C or C++.

How much of the early Android code was made by Google? Android existed for two years as an independent company before Google bought it.

The remaining 8 years have been written by Google.

Re: The rise of never-ending job interviews

#962
post #264

Earlier quoted context omitted.

At this point I'm pretty sure FAANG hiring is just a random walk. Every now again someone happens to have looked at all the questions they ask recently for that particular interview cycle (or avoid the trap ones like that) and that person gets hired (and then put on the ad targeting team or whatever).

I've mentioned before but at my previous FAANG gig everyone only looked at the resumes they were assigned to interview like 15 minutes before the interview time was scheduled down the hall / building somewhere. No one knew who they were interviewing or what was on the resume until they glanced at it while walking to the interview room. I suspect all interviews and the process are just made up as folks go along, and h…

One could argue that, when you're interviewing a lot of candidates and your acceptance rate is low, it makes sense to maintain a consistent approach to interviews. For example, asking all candidates the same question would help you develop a better sense for what a good discussion looks like, where candidates tend to struggle, how to help them along without solving the problem for them etc.

This is in contrast to tailoring each interview to a candidate's background.

With that, I think looking at a candidate's resume 15 minutes before an interview is not that unreasonable.

What am I missing?

(edit: this is meant for IC roles rather than management)

Re: The rise of never-ending job interviews

#963
post #353
post #338

Earlier quoted context omitted.

It is disrespectful, but it is a proxy test for how many hours you have spent reading and writing code in that language.

A while back Indian companies were notoriously famous for giving questions from Let us C, from Yashwant Kanitkar . The questions go like, What is the output of the expression below? int i = 10; ****++&&*+p; Followed by a myriad of options. Including things like Syntax error . Not sure how this measures language proficiency.

That's an easy one -- p is undefined. :)

(/me runs away)

Re: The rise of never-ending job interviews

#964
post #340

Earlier quoted context omitted.

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remembe…

I find it… troubling? That a technical interviewer can’t tell for herself whether your code will work. Wouldn’t you ideally want people who actually understand code to be giving the coding questions?

I think it depends on who gets to choose the programming language.

If you're interviewing for specific language skills, then what you say is clearly true.

If it's a general coding skills interview, I invite the candidate to code in whatever language they like. More often than not they choose a language I am sufficiently fluent in to follow along. In rare cases I need to ask them to explain a thing or two. In very rare (but generally quite fun) cases they choose a language I am totally unfamiliar with; this tends to lead to interesting discussions.

In all of those cases the full coding transcript is captured and, if necessary, can later be additionally reviewed by/with someone who knows the language well.

P.S. Also, their thought process and approach to problem solving is just as important as the code, and is largely independent of the choice of programming language.

Re: The rise of never-ending job interviews

#965

Earlier quoted context omitted.

When you're in such a dominant position they don't care about people being able to shake things up

Neither did IBM, GE, Oracle.

I'm not saying they're right to not care, but they don't

Re: The rise of never-ending job interviews

#966
post #943
post #477

Earlier quoted context omitted.

I had a recruiter obtain approval to have my technical review ignored because I pointed out so many flaws in it. At that point I had too much of a distaste for the process to continue. But I kept being approached by Google recruiters, kept recounting what had happened last time and asked if I could expect better this time. None could promise things had improved, and a few did express that kind of frustration. This wa…

I was getting HR hits like every six months and eventually I told them I would get back in touch when I was ready. Now I'm getting an email every month from FB, and about ready to do the same with them. The last time I passed the first and second rounds and Google let me languish on the third round for a month. I still probably would not have made it through, but it was surprising that my candidacy was dropped like t…

It says something about their HR systems that it's clear they don't review past interactions before doing this. To me that's a warning sign too - I'm less likely to consider interviewing if a company contacts me again and the interaction doesn't start with a pitch of how this time or this position is a better fit...

Re: The rise of never-ending job interviews

#968

Earlier quoted context omitted.

I don't think this was scripted; it's a typical sign of bad interviewers when they think that 1) they are smart 2) therefore if you're smart you have the same way of thinking 3) also you have the same knowledge (and gaps!) about irrelevant details Therefore instead of checking your knowledge they check whether you're like them. It's just amateurish.

This is pretty spot on

Downvoted??

Re: The rise of never-ending job interviews

#969

Earlier quoted context omitted.

I also did interviewing at a FAANG and this was not my experience. 1. We trained 4-5 times on each type of question. The first few were shadows, and then we did reverse shadows where someone watched us give the interview and gave feedback later. In one category I asked for and was allowed to reverse shadow an extra 1-2 interviews. 2. There was auditing. In debriefs where you discussed the candidate and reviewed notes…

This has convinced me never to work for a FAANG. That much interview rigor leads away from the "gut instincts" which lead to great hires.

Or it leads to people consciously avoiding subconscious bias and actually focusing on capabilities, not what your lizard brain thinks.

Re: The rise of never-ending job interviews

#970
post #843

Earlier quoted context omitted.

Not all younger developers have to jump through those hoops. There are plenty of companies that don't do that kind of nonsense, because they're trying to hire good engineers, rather than, specifically, engineers -- good or bad, that'll get sorted out later -- who will happily sacrifice their spare time to figure out how to jump through the arbitrary hoops that their jobs entail. Holding this kind of bullshit intervie…

> the only thing that made me more miserable than interviews like these was the work I got to do afterwards Can you give some examples?

It's very difficult, because making sense of the examples would require explaining all the convoluted decisions and corporate mechanisms behind them, and that would make it trivial to identify the companies in question.

I can give one example, I guess, since it's been a long time, it's a very common scenario, and this is an internal thing, so anyone who can identify it is either already there (tequila's on me this evening, mate) or has worked there before (I'm still up for tequila).

The buggiest component in one of the projects was the testing framework. It was a home-grown testing framework, incredibly slow (think "takes about 5 seconds to send a 20-character string over a 115200 UART line"), and it had a huge bug backlog.

Virtually all bugs got closed with WONTFIX. The person who'd written that monstrosity had made it up the management line, and his minion was now in charge of the team that allegedly maintained it. Since all sorts of bullshit metrics like bug fixing rate and total number of bugs and whatnot came up during quarterly operational reviews, a low bug count was nice to have. And since no customer ever complained of a bug in the testing framework, for obvious reasons, all that was required to keep the bug count to zero was an understanding between these two guys that all bugs would just get closed.

So you had to spend a few hours finding creative workarounds, since the two-line fix you'd come up with in five minutes would never get applied. And I mean creative. We had code that literally eschewed non-functional framework code by exploiting a race condition in its code in order to do RPC calls without going through the buggy framework code.

Now imagine you have to do something like this for every single task you do and you have a pretty good idea about how it goes. I mean you technically spend 100% of the time doing what you're supposed to do, but only about 30% of it is actually what you're supposed to do, everything else is mostly fighting cargo cult practices, senior engineering ego, and management disinterest.

Post reply on HN