0
31

[–] Dooberdoop 0 points 31 points (+31|-0) ago 

Strategically this just makes sense for the company hiring. Consider Google, which has been vocally lobbying for more h-1b visas for years. The only way they can get those visas is to "prove" there is a need for them. They can do this by simply making the interview process as ridiculous as possible. They are then able to "prove" that there are no suitable candidates in the US - get their h-1b's, import people from third-world countries and pay them slave wages. People who can never complain about conditions/fair-pay etc, because they will always have the threat of a visa revocation hanging over their heads.

Its like modern day indentured servitude.

0
4

[–] whisky_cat 0 points 4 points (+4|-0) ago  (edited ago)

It bothers me that tech elite companies like Google are the example. Try interviewing at a place which doesn't have a preference for young MIT graduates fresh and ready to commit their lives to making someone else a multi-billionaire.

0
3

[–] FormerlyKnownAsGkar 0 points 3 points (+3|-0) ago 

...except that after the first wave of really smart programmers show up, following waves will be even less able to answer the questions.

But it's silly to nitpick over H-1B. Everyone knows they're being abused, and if ICE and the IRS actually audited the companies using them, there would be fraud indictments flying all over the place. If I were king, any company that had more than a dozen H-1B employees would get audited with a proctoscope. (The law would also be amended so that no company could have more than a dozen H-1B employees, and the salary floor for H-1Bs would be $100k)

0
2

[–] Datawych 0 points 2 points (+2|-0) ago 

Google has one of the highest turnover rates of any major company. Seems weird, right? With all their sweet benefits?

Laundry service, nap pods, good health insurance, 24/7 cafeterias, on-campus housing...

That and 50% of logged hours must be spent on side projects, meaning when it gets down to crunch time and you need to put 50 hours a week into your project, you have to put in 50 more hours that week on side projects. Don't, and get reprimanded/written up.

Huh. Those all sound like things designed to make you work more hours for no extra money.

Talk to people who've worked at Google. Mental breakdowns galore. People crying in their cubicles/nap pods. Everyone is paid less than they deserve, because you have to be overqualified to even be considered for a job at Google. Everyone's a ladder-climbing, territorial brownnoser. Projects get cancelled for no reason. Managerial jobs are given to people who don't want them or know how to do them. Google criminally overpromises during the hiring process.

It's become the number one company for people with a "I'll work there for 2 years, then I'll be able to say I worked at Google, so I can get the job I really want somewhere else" attitude.

5
20

[–] rwbj 5 points 20 points (+25|-5) ago  (edited ago)

This individual seems to be rather clueless about the goal of interviews. When they ask you a question, the intention is to ask something that you don't know off the top of your head to try to get a bit of insight into your thought process. A maze solving problem is a perfect example of this. They're not asking you to recite A*, they're asking you to share how you'd go about solving it. So you might start by drawing a simple maze and interpreting your own thoughts into general control flow and then convert that into an algorithm. In fact simply code dumping A* would probably result in the interviewer asking a different question as that response is almost as useless as "I'm not a recent college grad. You expect to have this memorized?!?!?" The fact this individual is seemingly incapable of producing algorithmic thought without having memorized it is most likely the reason they were not getting hired for anything. All the above applies 100% for Google who has the reputation as a tough interviewer. Your credentials get you in the door, they don't get you the job. Your display of skills and logical/creative thinking gets you the job.

0
24

[–] snipez 0 points 24 points (+24|-0) ago  (edited ago)

While I agree with your statement about the goal of deeply technical interviews, the most important point of the article is "why am I doing algorithmic interviews when I'm applying for a front end position?"

While there still might be some merit to testing someone's problem solving skills, front end work tends to involve few to absolutely no algorithmic problems, and is generally very simple, and more about understanding the process and usage of the front end frameworks you use. I think if this guy was interviewing for a position that involves heavy data manipulation and storage, then sure, these are interview questions are quite important. That's generally just not the case with front end dev.

0
9

[–] ForgotMyName 0 points 9 points (+9|-0) ago 

The complexity of front end work is determined by your level of seniority and what kind of work the company does. I've written entire validation frameworks for the front end. The work ended up being pretty complex. I don't think it's unreasonable to expect front end devs to have some basic algorithm knowledge. A depth first traversal is trivial, you do that kind of thing regularly.

Even so, interviews aren't just a test of knowledge, but of personality. It's about learning - How does this person approach problems they're unfamiliar with? How will they respond when they don't have the answer memorized? I'd rather watch someone struggle to think something through and then finally admit - "I'm not really sure, I think I'm close but I'd have to ask around or do some googling at this point." Rather than throw their hands up and whine about algorithm questions in front end interviews. No one is going to hire the latter.

0
4

[–] pitenius 0 points 4 points (+4|-0) ago 

Maybe he should tell them that? I'll admit I'm rubbish in interviews, even having told people that their project was doomed to failure and only an idiot or masochist would work there, but I people do still seek me out and I occasionally get interesting work.

0
0

[–] tame 0 points 0 points (+0|-0) ago  (edited ago)

If I'm hiring a software dev specifically and solely for the rote UI work then sure. But if I'm not some accounting software company that survives by grunting out yet another quarterly revision of the same mediocre software package, then I want someone who can do more than just the grunt work, I want a team member who can analyze new problems and create new algorithms to solve them. And to test this skill, it's actually better to give them a problem to solve that they don't already know off the top of their head.

0
2

[–] FormerlyKnownAsGkar 0 points 2 points (+2|-0) ago 

They're not asking you to recite A*, they're asking you to share how you'd go about solving it.

That's the textbook answer. But you just have to read some of the replies on that article to see that a lot of interviewers don't know this - they expect you to know these kinds of algorithms off the top of your head.

I knew one old-school interviewer that asked every candidate the layers in the OSI model. He told me in all the time he'd been asking, only one person knew the answer. My response to that was "Doesn't that say more about you than the candidates?"

0
0

[–] rwbj 0 points 0 points (+0|-0) ago 

This may be the case, but I know for a fact that I what I said applies to one of the companies he listed by name - Google. While there certainly may be some issues with hiring at some places, I think there's also another issue at play here. In computer science there are a large number incredibly skilled individuals since for many the work itself is intrinsically rewarding. This means some otherwise smart and skilled, but not as skilled, individuals are going to end up being second tier candidates. At most companies they'd still be in the upper tier of engineers, but at a company that attracts all the top talent like Google - they're not even going to get hired. And I have 0 doubt that some percent of these people are going to reconcile their failure not as a failure of themselves but as a failure of the hiring system itself - How could they possibly not be hired?!? Clearly the problem must have been in the hiring system itself!

1
13

[–] virge 1 points 13 points (+14|-1) ago 

Sounds to me like this guy was interviewing at companies who were using high-level interviews to solve internal problems.

I've seen this more recently in the industry. It's an interesting way to try and reduce the bottom line when you have a headcount crunch (which seems to be the del-facto standard now, but that's an entirely different rant for another time..), but I can't imagine this is actually productive in the real world.

Well, I guess I have no clue. The abhorrent lack of data hardening and/or general understanding of technology in most Fortune 500 companies does go to show they are run rather sloppy.

0
4

[–] Drenki 0 points 4 points (+4|-0) ago 

I disagree, none of his exercises were out-of-the-ordinary.

0
6

[–] virge 0 points 6 points (+6|-0) ago 

I disagree. Any exercise which does not have an immediately identifiable connection to the job responsibilities of the job you are applying for (applicable to most, if not all, of the examples used by the author) then I consider nothing about that scenario to be "ordinary".

0
8

[–] dizzydog 0 points 8 points (+8|-0) ago  (edited ago)

After about 10 minutes we jump right into whiteboard problems — implement a breadth-first search (BFS) algorithm.

The thing is, it takes less than three seconds with Google to find a perfect implementation of a breadth-first search algorithm, and if you actually wanted to implement one in production, no programmer in their right mind would write a solution to a known problem blind instead of using code that's already been tested a few trillion times. If the test is to discover the thought process I would follow on the job if I knew I needed to implement a breadth-first algorithm from scratch, my thoughts are that I would use Google.

Maybe it would be better to ask what the advantages and disadvantages are over other means of tree traversal, or whether I have ever used it before, which I actually have, in a chess AI, whose code they can look at if they want... To see if I actually know why and when I would use it is more important than the details of how one is implemented, when that is public information that is trivial to look up, I would think. Good judgement and understanding is not.

0
2

[–] whisky_cat 0 points 2 points (+2|-0) ago 

I've done tree traversal for a flat array of nodes with only parent_id references as the main association across thousands of objects. This was based on the linux inode pattern.

My first draft of building the tree was shit, 10s of thousands of computations. My boss showed me that a dictionary (or literally a JS data object that saved some IDs) would solve almost all of that performance. We ended up looping the nodes twice, which took the feature from factorial complexity (something like N^n, to 2N, and I don't know big-O notation at all).

So I have respect for that skill, but as a standard frontend dev it's mostly irrelevant. Such a frontend dev will be already employed at a major performance shop. e.g. Google.

0
6

[–] 51rH0n3y84d93r 0 points 6 points (+6|-0) ago 

0
1

[–] J_Darnley 0 points 1 points (+1|-0) ago 

Underrated, thanks.

0
6

[–] 7even6ix2wo 0 points 6 points (+6|-0) ago 

I am also very unhappy with the sometimes emphasis on knowing factoids in interviews that could be looked up in 3 minutes at a desk. One time some company brought me in for an interview and I'm pretty sure they were filming me not the knowing to the answers I had written down at home for phone interviews. "Sorry dude, I don't recall what the difference between where and having is but I know where to google it."

2
5

[–] WillyWillyBumBum 2 points 5 points (+7|-2) ago 

How many people can actually write BFS on the spot, without preparing for it in advance?

While I agree with the sentiment (was rejected several times a few months ago), knowing basic algorithms is rather important. I would assume most competent programmers can write BFS on the spot. But I agree that interviews could be improved. I've had luck with simple interviews at very small companies/start-ups; no BigCorps for me

1
9

[–] rwbj 1 points 9 points (+10|-1) ago 

Again I don't even think you need to have BFS memorized. As long as you conceptually understand how a breadth first search works it's trivial to throw one together. I mean as long as you grasp that it's peers before children - which ought be entirely intuitive, the rest is trivial.

0
3

[–] ForgotMyName 0 points 3 points (+3|-0) ago 

Seriously, I got to that part and had to stop reading. This guy is a huge baby. How you write it is IN THE NAME. I haven't taken algorithms in forever either but you do this kind of stuff all the time. You need to look through an object tree for something, you're generally going to end up either going breadth first or depth first. This isn't something you do every day but I'd say I do it once a month.

0
2

[–] WillyWillyBumBum 0 points 2 points (+2|-0) ago 

Never said it had to be memorized. I almost agreed with the blog author when I couldn't remember how to do BFS. But thought I'd challenge myself and figured it out in about 15 seconds, with the deque and all.

0
2

[–] whisky_cat 0 points 2 points (+2|-0) ago 

Yep, I just avoid the big corps. There's 10s of thousands of companies seeking less-than-elite frontend talent. The market is huge.

0
0

[–] tame 0 points 0 points (+0|-0) ago 

I disagree with it. If they can't write a BFS or DFS on the spot, from first principles, then I don't want to hire them. Sure, maybe when they have access to stackoverflow.com they are capable of cut-n-pasting their way through most business application development jobs, but I want someone who can solve new problems which don't have example code available.

0
1

[–] onegin 0 points 1 points (+1|-0) ago 

But the problem is, a bunch of play-the-game candidates will memorize tree-traversal (and other stock problem) solutions, so in comparison anybody who is trying to solve them from first principles on the spot will look unprepared or subpar.

0
4

[–] TheCompanionCube 0 points 4 points (+4|-0) ago 

I wonder if this is a geographic thing. I did interviews on the east coast about 3 years ago for various sw positions and they were all easy. I even got an offer from the place where I thought I failed the interview because I rambled through one of those "how many piano tuners in city" questions.

0
1

[–] whisky_cat 0 points 1 points (+1|-0) ago  (edited ago)

It is. Logically, as the biggest names in tech are mostly on the west coast. That's a sweeping statement, of course there are big companies to the east, but they're not as hungry for C.S. geniuses, they want production. I gotta think 95% of frontend producers out there, with legitimately valued jobs, can't pass C.S. questions @ Google/BigName.

load more comments ▼ (8 remaining)