[jokh]

That is true, but in order to get the jobs you described that pay reasonably well you still need to solve algorithmic problems on Leetcode or CTCI. And sometimes knowing different data structures and algorithms do come in handy, so some problems on Leetcode can be considered realistic.

[AnimalMuppet]

No, you can get there by finding jobs where the interviewers/hiring managers aren't using Leetcode as their filter. (They do exist, even if they're not as common as they should be.)

[jokh]

That's why I said "pay reasonably well". It seems to me that most places that don't interview and filter candidates by asking algorithmic problems don't pay as well as those that do. That's just been my experience as a student that's interviewed for internships and is going to start interviewing for new grad positions in the fall.

Also

> (They do exist, even if they're not as common as they should be.)

I'm curious why you think interviews _should_ be non-algorithmic. How do you propose interviews be done? How else are you supposed to find if someone can employ critical thinking + has the necessary programming skills? And yes, most interview questions _are_ original and not straight from Leetcode so they do demonstrate critical thinking + programming skills.

[trcollinson]

You’re thinking rather short sided here. There are a lot of ways to find out if someone can think critically and also has the appropriate level of skill at programming. I prefer to give them a set of much more real world type scenarios to see how they will handle things. Often I do this in a paired programming scenario. We both sit down. I drive they navigate and we spend 20 - 30 minutes trying to build something. The something is never anything that is going to go into production. Just code that is real and useful and can show me how they think through a problem and whether they can catch mistakes in code as they happen in real time. Lately I’ve been a fan of making a shopping cart (since the software I build doesn’t have a shopping cart).

I keep it very short. I try to make it low stress. I try to make it fun and funny. Why? I really want to know if the candidate can work with me and how they will work. I don’t care one bit whether they can remember the big O notation of a red-black tree search or whether they know how to reimplement a complex datatype. I care how they will work with me in my environment.

You might say “you’re method is just too simplistic. People can game it and get through.” It’s been accused of that before. And frankly, I can memorize algorithms and game that interview. Try gaming me while we pair on some code and I try to toss in a few roadblocks. Try to game me as I try to see how you will react as we work together. It’s hard, and my methods have been quite successful for me.

As for the pay, I don’t pay people what Amazon, Google, and Facebook pay. But I pay very well and people stick with me so it seems to work out.

[AstralStorm]

The other good test is to toss some intentionally cleverly buggy or incomplete piece of code to analyze and debug, since a third of the job is debugging.

And by bug I do not mean super hidden tricky language feature you get to look up on language standard to not misuse.

[ta1234567890]

At one of my companies we pay SF/BayArea market salaries and the way we hire (pretty much everyone, not just programmers) is: 1) short (10-20 min) phone interview, 2) if it seems like a good candidate we invite them for a paid test run, usually 2 weeks of actual real work, either remotely or in person, 3) if it works out, they get hired.

Pretty much nothing will accurately predict how well someone is going to do on the job. The best approximation is for them actually doing the job.

Also, the two most important things that we look/test for throughout the process are: 1) how good of a fit the candidate is for the team/company (do they get along with their team?) and 2) how enthusiastic they are about working with us (did they do some research on us ahead of time? are they excited about the opportunity?)

[MisterOctober]

"Pretty much nothing will accurately predict how well someone is going to do on the job."

^ this is a doggone well-phrased and accurate summation of the challenge of team-building. Raw capability is by no means a predictor of how well someone'll work with the organization.

[MrPowers]

I'm sure this is effective, but are folks really willing to agree to this? Do you pay for the 2 weeks of work? Do candidates ever say no to this arrangement?

[robjan]

Does this not reduce your pool to people who are actively looking? That excludes most people, especially the top candidates who are never out of work.

[diminoten]

There are drawbacks and advantages to every hiring process, it's possible they've determined this set of advantages/drawbacks works best for them.

Besides, it's possible to take 2 weeks off of your current job.

[vtainio]

Is the 2 week paid work done only for candidates that aren't currently employed or how does it work?

[akho]

You can’t use this process to hire someone who already has a job. So you’re limited to college grads and the otherwise unemployed. That is a pool not everyone can be content with.

[m0llusk]

Employees ready to move on often have substantial time off built up and also have the ability to negotiate additional time flexibly.

[deathtrader666]

I am actually game for this 2-week trial. How do I contact you?

[toolz]

Just my own little anecdote, but I was able to get into upper middle class after 4 years and no degree. I've never completely passed an algorithms interview either - most of my jobs haven't had algorithm filters. I'm now doing functional programming in a cool language for a living.

Most people I meet haven't had my path to success, but it is possible. My gut feeling is that I'm a small statistic because people give up quite easily when they think their goals are unattainable. My first programming position took me 15 interviews to land a job!

[awinder]

Take home assignments, discussions about work history, problem solving at an architectural level, the list goes on. Programming to algorithms in a live interview setting is about the least realistic way to gauge real job aptitude. Tons of thought leaders write about this, and tons of places implement more rational hiring practices.

On the “pay reasonably well” line, the average new college grad salary is 50K. I’d wager that the vast majority of salaries in the field exceed that. The googles of the world pay way in excess, and they may make you do some stupid dances to get in the door, but that’s not the real world, that’s just one weird part of the world.

[jokh]

> problem solving at an architectural level

That's a problem for people who haven't done internships and have just graduated. Architecture skills and knowing how things are/should be designed come from experience, which a lot of people don't have.

On the other hand, algorithms + data structure knowledge and how they're applied do not really require experience, just knowing fundamentals well.

So your method is definitely good for experienced people but not for new grads/interns. And these are methods the industry employs anyway — big companies do stress more on system design for industry hires, less so for new grads + interns.

[AnimalMuppet]

First, I never said that people shouldn't ask algorithmic problems. I said they shouldn't ask Leetcode-style questions. To me, that stood for a whole class of problems where you have to know the area in order to be able to solve the problem. When you have people talking about studying for interviews, I'm arguing that those are bad interviews.

Background: I've been a programmer for 33 years. I have never (directly) used a tree of any kind. (I've used STL and Java maps, which I think are trees under the hood.) Asking me to do something with a tree in an interview question is therefore probably a sub-optimal way of determining whether I'm a good fit. Yes, I know what a tree is. No, I don't know it like the back of my hand, and I don't know the algorithms in detail. Yes, I could probably figure it out during an interview. But expecting me to know that background when I come into an interview, when I have never used it so far in a pretty long career, and so I'm probably not going to actually use it at the new place either... that's asking me to memorize a bunch of stuff that isn't actually going to be useful on the job. That's a bogus interview approach.

Algorithmic questions should be something that the interviewee hasn't memorized the answer to, but also that they don't need to have memorized a bunch of background or know the "trick" to be able to answer.

Now, I'm in kind of a different world. I've worked mostly in embedded systems. If you're interviewing for a job where they use a lot of trees in their data structures, you probably ought to know them. If you are interviewing at one of the big boys (Google, Facebook, et al), where an improvement in the structure you use to represent the data can mean that you need several thousand fewer machines, they are going to really care about your grasp of the nuances of data structures. But, despite Google's size, most jobs are not at Google, or at that type of place.

If you're going to classify only Google, Facebook, Amazon, and their ilk as "paying reasonably well", then I do not agree with your definition, but I will agree that you'd better be able to pass Leetcode-type questions in their interviews.

[hueving]

>original and not straight from Leetcode so they do demonstrate critical thinking + programming skills.

Leetcode style questions almost never require anything resembling critical thinking. The only thing they demonstrate is problem solving under pressure.