Hacker News Reader

Comment by joeax | Hacker News Reader

They eat large sprawling problems for breakfast, but they balk at 45-min algorithm challenges.

If a candidate can solve large, complex problems but bombs your interview, the problem is your interview. TripleByte should focus on this problem and educate these companies on effective interviewing techniques. For example, if your interview overemphasizes coding challenges, puzzles, quizzes, or otherwise feels more like being on Jeopardy than real-world applicable, you're doing it wrong.

Candidates should be focused on their skill set and filling in gaps (i.e. I've toyed with Python but I see it being in demand so let me get better at syntax, packages, thinking in pythonic way).

View on HN

Okay, but the problem is, 45-60 minutes is usually all hiring managers have to assess a candidate. What can you do in that amount of time to assess someone‘s real world performance? Having a high level conversation about technology and problem solving approach helps but often doesn’t translate into writing code. Tech-stack specific challenges are no good because general programming ability is more important, you can learn a new language on the job. Algorithm puzzle problems aren’t great because then we’re selecting for people who spend a lot of time on hackerrank or whatever.

Maybe effective programmer hiring is just an unsolved problem.

What's so friggin' different about hiring software developers that we've gotta get all weird about it and come up with some brand new thing? What's the hiring process like for other office workers? How about for other technical or specialist roles that are somewhat similar to software developer? Engineers of various sorts, maybe? Accountants? Hell, lawyers even? There's got to be some set of existing practices that'll fit this just fine. It's simply not. That. Special.

It kind of is tho. Also you should research what kind of shit accountants have to go through to get hired at big 4 for instance. And lawyers have to pass bar.

Lawyers pass the bar once.

True, cle is mostly a joke lol

They pass it once, at most. Many take it many times.

Many things happen:

* You hire people who end up not being able to do the work (I hear my wife complain about this problem in accounting just about every three days)

* You end up needing more stringent certifications than exist in comp sci land (you mentioned lawyers, so that's one with bar exams, but also accounts with CPA exams, professional engineers, doctors, etc)

* You get proof of prior work

* You rely heavily on recommendations, with all the pros and cons there

> You hire people who end up not being able to do the work

Funnily enough, I've heard the same thing from some friends who worked at companies with algorithmic interviews.

> You end up needing more stringent certifications than exist in comp sci land

That sounds great. You just have to study up and take a very hard exam at the beginning of your career instead of having to study up and take a hard exam every few years.

> You get proof of prior work

And what about Github? Most employers want to see proof of prior work unless you've got a very good excuse.

> You rely heavily on recommendations, with all the pros and cons there

This may be the only decent argument against the accounting/engineering/medicine interview. Even with good performance, recommendations are a crap shoot (did you get along well w/your boss, are they pissed you're leaving, do they refuse to give out references to anyone like one contract employer I worked for for a year a long time ago).

But then again, puzzle interviews are also a crap shoot.

To be clear I wasn't arguing anything, just stating what happens. Things are different in some ways, but not all (recommendations and proof of work are common in programming too)

In my experience, recommendations aren't very common in programming, unless you're talking about referrals by former supervisors/colleagues to some job opening.

Have others had a different experience?

Recommendations really only come into play when you're talking about the best engineers. In which case, you're effectively no longer interviewing, just getting people in your network who say they must hire you or tell other people in their networks they must hire you.

I would consider those as more referrals, not recommendations (which implies the traditional job recommendation process).

GitHub can't be used in Graduate interview efficiently, and those one could be probably the most problematic. If a candidate has work experience, you can at least assess that he can do something

My brother is a mechanical engineer, and his org hires by bringing in graduates on a low salary, moving the competent ones to roles that make use of their competencies, and moving the incompetent ones to roles that are pretty much the same as unskilled technicians. Sometimes the boss meets a candidate at a conference or over beers and fast-tracks them. They have literally no women in the entire engineering department.

I'm not defending whiteboarding the knapsack problem so much as I'm defending the difficulty of hiring skilled workers from different walks of life. Tech isn't special, hiring is just hard, and a lot of other industries are actually worse.

The software engineer analogue of this would be consulting. You hire everyone out of college. Start them off at a salary such that they are still net positive even if they only ever stay at the lowest possible billable rate. If you get good enough to command higher rates (or the effective rate through increasing the success rate of projects), you'll keep on getting commensurate raises.

I think other professions emphasise past experience and referrals more. That and official credentials, especially in certified professions (I.e. Medicine).

That said, I think all interviews have an element of silliness to them. I know a financial consultant who was quizzed over articles published in the days financial times newspaper. Also know one of our analysts makes candidates do long division on paper! Don't forget the infamous how many golf balls can you fit in a jumbo jet kind of thing.

> Hell, lawyers even?

It's pretty terrible. There's no other profession that's quite as snobby as the legal profession. If you want to go work for a top firm you need to have gone to one of a handful of law schools. While there you need to have gotten good grades in your first years' classes so that when on campus recruiting happens at the start of the second year you get an interview. These OCI interviews are almost entirely what the tech industry would call culture fit, with all the implications of bias that implies. One a summer position is obtained, the job is yours to lose. Do reasonable work, don't get drunk and vomit on a partner's spouse or blow off your third year classes and you will probably get a job offer with the firm you summered for.

I don't think this is a process any other field should try to emulate. Whiteboard interviews may have their flaw but it's a lot better than:

  Did you go to Harvard Law &&
  Did you get top 1/3 grades as a 1L &&
  Do you remind the partner you are interviewing with of himself and/or his kid

A lot of fields are similar in pretty lame ways like consultants from MBAs, accountants, lawyers. For all of them. Getting into the tier 1, tier 2/good boutique place is a rigid crappy system. I can’t remember exactly how investment banking and other main MBA sort of jobs work but I think they are similar too.

Friends in more general office jobs like HR, managers, etc, it doesn’t seem much better. It’s different than how to get a software dev job, but to say it’s been better would be a bit much.

I've agree with the difficulty you describe - even with 4 hours of interviews.

I've come to the conclusion that one (or both) of the following might be best:

- a small take home project with a reasonable due date (say 5-8 days) that is representative of the kinds of work that is expected on the job. Then, a 1-2 hour code walk through and presentation. Candidate should expect to build, run, debug and describe the code and architecture, tools choices, show source control use etc.

- a 3 month probationary period with a fairly narrow starting role that all new hires expected to be able to code are required to go through; ex: fixing bugs on project X; ramp-up and demonstrate _______ and _______ on project Y.

Doing the take-home project is certainly difficult for some candidates who may have a hard time carving out time to do it - but the hiring manager can offer some flexibility here - and this seems like a much better approach than taking online code quizzes.

The 3 month probationary period seems like a way to detect other on the job performance or interpersonal skills issues that may be a cause for disqualification.

These are interesting ideas. It seems like a hurdle would be getting candidates to agree to the conditions. What incentive do I have to pick a company that requires a 3 month probationary period when I can just get very good at dynamic programming and topological sorting and ace a one day interview at another company?

Also, I find that take home projects in particular are biased against people without free time, eg, parents.

> when I can just get very good at dynamic programming and topological sorting

might work at one place, but the next will ask completely different questions. You can’t know everything.

The pool of problems asked at these places is pretty limited, which is why websites like leetcode are a thing. It's a shitty situation, but that's the reality.

I haven’t found that, one place will ask about CS, the next DBs, the next tools, and stacks have exploded.

The problem with all "contract to hire" schemes is you essentially set yourself up for failure on the labor marketplace. Unless you're offering some other compensation, why would any talented candidate take your contract to offer job over the firm next door that's hiring them flat out (assuming both of you pay market rates). Not to mention you shut yourself out of any nonlocal market.

Especially in the US, asking an employee to give up even more rights is a hard bargain. You run the risk of naturally selecting for employees that can't get hired anywhere else (which tend to either worse, or at the very least require more investment; something you're not willing to do or why have you made them use their time to do a take home and start this contract to hire business)

In my appraisal, more firms just need to recognize that they don't need half the technical skill they think they do. Building a CRUD back end or a mobile app doesn't take deep algorithmic horse power and the engineers you've managed to retain to administer the interview probably aren't qualified to do so anyway.

>a small take home project with a reasonable due date (say 5-8 days) that is representative of the kinds of work that is expected on the job. Then, a 1-2 hour code walk through and presentation. Candidate should expect to build, run, debug and describe the code and architecture, tools choices, show source control use etc.

The problem with this is that talented developers generally do not want to work for free on someone else's proprietary software and there is a very real risk of companies trying to abuse this practice to extract free labour from candidates the closer you get to "work that is representative of the kinds of work that is expected."

I do not want to spend hours of my life on unpaid labour for a company that may or may not hire me. Give me the 45-minute algorithmic challenge that puts me on the spot every time.

I also strongly suspect your 3 month probationary period would be an effective anti-signal as well, useful for attracting desperate candidates rather than the ones you really want. You can't reasonably expect a senior engineer to jump at leaving a secure position for a 50/50 shot they might be unemployed in 3 months because they're "not a good cultural fit."

> work for free on someone else's proprietary software and there is a very real risk of companies trying to abuse this practice to extract free labour from candidates

This may happen in some places, but in practice I've never seen a task which actually could be applied anywhere. Most of the time these were toy projects, or simple exercises.

I think you'd easily notice if giving you the test was worth more to the company than all the recruitment time spent on taking to you. It's not free labour if you end up spending hours with each candidate, splitting up real work into "exercise chunks", integrating wildly different styles, validating results, etc.

I've seen this when the company switched the "exercise" as a no-wait-solve-this-one-instead which was fairly obvious it was a work-related task that was being farmed out to candidates.

To your second point, I'm a fairly young engineer with 1.5 years experience, and I'm not leaving my secure job for a shot at being a good 'cultural fit' for some other company.

Financial security is important, and I would put up with a lot of shit from my company before I'd consider taking a chance on another one like that.

Although I know some companies (my current one included) have a 3 month "probationary period" where they've only ever let 1 person go at the end out of approximately 150 since I've been there. It's just to make sure you're not a complete goon.

Problem is, it could be really hard to tell apart a company that has a "probationary period" like mine, or a real time that they judge you at the end.

I think you’ve mentioned a HUGE part of the interview process that interviewers forget: you only have 60 mins. 45 mins if you leave time for questions (which you always should). It’s an incredibly difficult task, and deserves significant effort, as opposed to just thinking “oh interviewing is easy”

I used to be a lead software engineer and conducted dozens of interviews and phone screens. I would simply look at existing problems I had solved recently and ask the candidate how they would solve them. If they came up with something on par with my solution or better I would recommend them for a second interview. If they talked around the problem and just dropped buzzwords I knew right away they weren't a good match and/or didn't know their stuff.

This approach is straightforward, real-world, and you can find out about a person this way in as little as 15 minutes.

Shhhh stop giving away my trade secrets for hiring better than everyone else!

I have had a strong hand in the technical interview design at my company. Push back on 45 minutes. I've put a line in the sand that we at least an hour for code and an hour for design, and we schedule those next to each other if we need to give more time to code.

For code, the key is to find a recent problem your team's have recently had to actually solve. Distill it down. As a interview question designer, give yourself 1/4 to 1/3 the coding interview time and see how far you get implementing the solution. That is the bar: don't expect a candidate to be able to get further than that in the whole time block. You also want to budget time to talk about productionizing the code (metrics, logging, monitoring, etc).

I had a question that I wanted to give and required a couple passing unit tests. After applying the 1/3 time rule, I realized that my question was unfair and I had to alter what I started with.

You can read my resume and call a few of my references. You can ask me to explain my previous work. You can ask me how I'd approach a problem you've worked on. It's not very complicated, and for some reason software hiring worked just fine with this approach up until 10 or so years ago. If you have a bad hire, you make them do shit work until they quit, or you fire them. I've worked with a few bad hires over the years and the team adapted around them just fine and work still got done.

Reply on news.ycombinator.com