[chowells]

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

> Ughhh, should I tell him?

Yeah, that's where I stopped reading. This isnt specialized knowledge. If you know how to program, you can write a BFS. The entire algorithm structure is in the name. The only extra details you need to remember or figure out are "use a FIFO for tracking what to check in the future" and "make sure you don't go backwards". Neither is some great secret. They're obvious if you sit down and think through (or talk about with the interviewer) the structure specified in the name of the algorithm.

This person is either not a good programmer or has a very poor attitude about solving new problems.

Hiring isn't broken. I'd reject this guy too. Knowledge about a specific technology is a lot less valuable than general knowledge and willingness to explore.

[dnautics]

My sentiment would be: "hiring is broken, but I'd reject this guy too".

[rammy1234]

you know what is broken , empathy. Every individual have certain skills and strong and weak points. to that effect, have empathy and understand person being interviewed is not in best comfortable position as the interviewer. In an uncomfortable situation, where everyone is peeping up what you do makes few people thinking messed up.

Programmers need a zen place to concentrate and focus. "Homework" assignments should be a good measure to test skills and questions on decisions made on his and how would he improve a code given the use cases would be more comfortable and now we are level playing field. my two cents.

[genezeta]

Unfortunately, homework assignments are being abused to the point of being absurd.

Around here, the trend is requiring a 16-20 hour assignment just after a brief 15 min phone call, almost before starting the process at all.

Not only it is a ridiculous amount of effort to ask someone who may already be doing 8 hours a day programming but it's also a problem for the company. Either they have to spend significant effort evaluating each candidate's submission or -more likely, sadly- they only give it a perfunctory look and discard many on first glance. And considering that often the person doing the evaluation has his own tasks to do and is doing it on some spare time, they will tend to not make much of that effort.

The result is the company still needs to do significant effort and the candidate gets frustrated because they have had to spend a significant amount of time and, after having to wait for a couple of weeks -at the very least-, they get generic and useless feedback saying simply that they did not meet the expectations or whatever.

I would not mind at all doing a two-three hour on-site assignment. If you're there, they will at least have to make a similar effort as you are. I find this much more fair both as a candidate and as an employer.

[rabidrat]

> I would not mind at all doing a two-three hour on-site assignment. If you're there, they will at least have to make a similar effort as you are. I find this much more fair both as a candidate and as an employer.

I've had this exact thought. I got interview homework last year, was told to spend "no more than 4 hours" on it, etc, was mildly interesting. The next interview we'd have a discussion about the code and I'd present my rationale for various design decisions etc. But then I got the email that the interviewer had reviewed the code with an engineer and they decided not to move forward because there was a mistake and they "thought there would be more testing"! I felt that it was quite imbalanced to have spent 4 hours on this task, only to have it rejected without discussion after a short review.

So in the future I'm going to suggest that I'll be happy to do whatever homework assignment as part of a pairing exercise. That way I can see what it's like to work with them too.

[Rooster61]

If a recruiter/hiring manager sends one of these nonsense assignments to me, I refuse them outright and thank them for their time. It only took me one frustrated night trying to bang one of these out after a long day of work to learn my lesson. This method of testing a potential hire is lazy, ineffective, and frankly rude IMO.

[scarmig]

The strategy here is to set aside one hour to code, write the code, send what you have after an hour and say what remaining work needs to be done, along with reasonable estimates of remaining time (noting that you're too busy to spend actually doing it).

Your success rate will be no less than someone who spends 15 hours doing whatever bullshit assignment there is.

[Rooster61]

I did exactly what you just suggested. I never heard back from that particular recruiter. Bummed me out at the time, but now I just laugh at it.

[quest88]

I find empathy hard here. If the author had said they froze or panicked and blanked on BFS, then that's understandable. But that's not what happened here.

[y-c-o-m-b]

> I find empathy hard

"If only the author did these very precise things that they just so happened not to do, THEN I would find empathy". I'm pretty sure that's not how empathy works.

[jermaustin1]

> This person is either not a good programmer or has a very poor attitude about solving new problems.

He probably isn't a good "programmer." He is a web developer, and has projects that are basically CRUD input and output.

He can stitch together various different components to build a functioning end product. This is a fine skill for most agency type jobs, and he will likely have a long prosperous career as a contractor.

[sigsergv]

You don't have time to design algorithm on site, you MUST write it down exactly right now without errors. That's the problem.

[chowells]

That's not how interviews work. You are not alone in the room being judged by an all-seeing eye. You are talking to a human, and each of you is evaluating whether you want to work with the other.

As an interviewer, I'm always happy to talk to the candidate about the question I ask. I'm perfectly happy to answer "What is a breadth-first search? Why does it solve this problem?". I'm perfectly happy to talk about algorithms with them, and ask leading questions if the candidate explains where they're having difficulty.

As a candidate, I'm not interested in working with an interviewer who doesn't approach the interview the same way. Remember, all interviews are bidirectional.

This person's stated reaction to the question was anger that it was asked. Most likely masked in person, but even masked tells us a lot. It tells us he didn't actually talk to the interviewer. If he had talked to the interviewer and got garbage back, he would have been angry about how awful the people were, not that some technical question was asked. If he'd talked to the interviewer and got useful information back, he wouldn't have thought it was a bad question. The only options left are trying to stumble through it silently and getting it wrong, or sullenly saying "I don't know" and moving on.

And that's the problem. A good programmer isn't measured by being able to make things. A good programmer is measured by being able to work with others and make a positive contribution in a group. Everything this person is describing is how to make a bad first impression during an interview. Maybe he's a great programmer, but he's utterly failing to actually convey that in the important aspects during the interview.

I wouldn't hire him, and this writeup is exactly why. He needs to demonstrate that he's someone people want to work with. This article does the opposite.

[jermaustin1]

>As an interviewer, I'm always happy to talk to the candidate about the question I ask. I'm perfectly happy to answer "What is a breadth-first search? Why does it solve this problem?". I'm perfectly happy to talk about algorithms with them, and ask leading questions if the candidate explains where they're having difficulty.

This is something I feel a lot of interviewees aren't aware of, you DON'T have to know EVERYTHING.

I didn't know what a BFS was (I am primarily a front end web developer), so in an interview, I'd simply ask "Could you explain what that is? I'm sure I can find some way to do it."

As an instance, I looked up "Breadth First Search" on google just now, and saw that its just a way to search a tree one generation/level at a time. Once I knew that, the naive approach is simple (I'm sure there is a better way). Start a queue with node(0,0), and loop until the end of the queue, if you don't find the correct value, add the node's children to the queue, and keep going.

I totally feel for the guy, I've been rejected more times than hired, that's for damn sure, and each time is a HUGE blow to the ego, but you have to pick yourself up. I feel he is a great contract developer (not a dig, I am also a contract developer), but not necessarily someone I would hire full time.

[Izkata]

> Once I knew that, the naive approach is simple (I'm sure there is a better way).

No, that's it. That's why so many are ragging on him; it really is that simple.

[sigsergv]

I have asked HR persons (in large corps) and got clear direct answer: you MUST solve two tasks on the interview, it's a necessary condition. If you don't solve within the hour you are rejected. In small companies conditions are much more relaxed, but in large corps where interviewer screens hundreds of applicants he/she just don't want to waste time.

This system is corrupted but looks like it suits big corps just fine. I have never evet been asked about my real experience on large corp interview. They just don't care about your github. Small companies asks about experience, but unfortunately some small companies copy FANG approach to interviews, cargo cult is magnetic.