Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tech Interview Handbook

yangshun.github.io

Post reply on HN
Print view View original

291–300 of 344 posts

Re: Tech Interview Handbook

#291

Post by davidjnelson »

deanc wrote: post #190
PeterisP wrote: post #140

Earlier quoted context omitted.

Your problem actually is a good illustration of the whiteboard test problems. I just tried it, and it was trivial to do in a minute or two on my laptop. However, I did took note of two syntax mistakes that I made in the python REPL that were immediately obvious there and took seconds to fix, but which I most likely would not have noticed on a whiteboard. So there's quite a bunch of problems where if the acceptable "f…

Nobody is punishing trivial syntax errors in whiteboard interviews. Nobody is taking your code and checking it runs. It’s about your approach to problem solving and your ability to communicate that.

A cs professor at Stanford that hired at google said they _absolutely_ care if your code compiles and works correctly. This is the “coding fluency”[1] metric. The author of cracking the coding interview also touches on this.

1. https://www.programmercoach.com/2017/04/interview-insider-co...

Re: Tech Interview Handbook

#292

Post by closeparen »

triceratops wrote: post #243
lawn wrote: post #152

Earlier quoted context omitted.

Because these problems encourages you to write unreadable code. It makes sense when you write it, because you can fit it in your head, but you never have to revisit it after having passed the problem. It encourages one letter variable names and other quick hacks in the name of speed. They work against creating readable, understandable and debuggable code which is much more important in general than being able to solv…

> Because these problems encourages you to write unreadable code. First off, no, writing good code in an interview wins you additional points. Second, why do you think candidates can (or will) continue doing that on the job? New employees aren't allowed free rein to check in code from day 1 at most places - trust has to be earned. And I don't think any decent company allows check-ins without review.

Code reviews are good at catching oversights and at giving design & implementation pointers to people acting in good faith. Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good. See the bullshit asymmetry principle. And once you hire two of these people, they'll just review each other.

Re: Tech Interview Handbook

#294

Post by sieabahlpark »

bakuninsbart wrote: post #181
sieabahlpark wrote: post #164

Earlier quoted context omitted.

Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase. Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.

So I had the same problem for a while, it was quite absurd, because I got through my uni courses, could decently code in Haskell and some other things, but never figured out the appropriate position to put an if clause. I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages. Point of this comment is th…

No see I wish they had any redeeming skill, he always asked an engineer to assist him with anything. They couldn't figure out anything on their own. It was shocking someone could complete the interview (small problem with a solution that is essentially explained, make x do y) and completely fail at building their own solutions without guidance

Re: Tech Interview Handbook

#295

Post by closeparen »

fogetti wrote: post #200

There is something I cannot understand and this has already become a cliche: > Technology industry is an extremely fast-moving one. Many technologies used today didn't even exist/were popular a decade ago; in 2009, mobile app development and blockchain were pretty much unheard of. Engineers constantly need to upgrade their skills to stay relevant to the demands of the job market. Engineering is a great career for pas…

Teachers, doctors, lawyers, professional engineers, and many others get their licenses revoked by the government if they fail to go back to college and take classes every few years.

Re: Tech Interview Handbook

#296

Post by dccoolgai »

mjfisher wrote: post #273
dccoolgai wrote: post #183

Earlier quoted context omitted.

1) Resume screen 2) 30-minute coderpad/codeshare exercise on a problem/pattern you actually use/encounter during the course of your work over phone. (No inverting binary trees). Expect a 20% pass rate here. 3) Reasonable take-home problem that you've timed 2 of your own staff completing well in 50 minutes. This is where you will get the most complaints from applicants, but that's OK. Let them select themselves out of…

I'm curious about the codepad/codeshare approach right at the first touch point. I fully agree that screening actual tech skill early on is important. Do you not find that you commit a lot of engineer time to codeshare interviews that don't work out further down the line?

Codeshare portion is 1 (typically senior) engineer for 30 minutes. Not that bad on a large enough team with everyone taking turns. I should add that we have 3-4 "canned" questions that the HR rep writes down the answer to, so even in the "resume screen" there are a few super-lightweight technical questions.

Re: Tech Interview Handbook

#297

Post by matz1 »

shivawu wrote: post #285
matz1 wrote: post #228

Earlier quoted context omitted.

>I may learn react via books/tutorials, get a great score in the test, never use it and/or forget it by the time Thats one of the point of programming test, there are tons of framework/language out there, every company might use different language/framework, a standardize test streamline the interview process, make it easy for you to interview in many different company. >Given that it's not clear as to what problem s…

> Thats one of the point of programming test, there are tons of framework/language out there, every company might use different language/framework, a standardize test streamline the interview process, make it easy for you to interview in many different company. As you said, they're very different. The thing is it might not be possible, as the technology develops and diverges, to have this one standardized test. > It…

But the basic/fundamental like algorithm and data structures are still the same.

Yes just like grinding leetcode, is at least shown that you are willing to put the effort.

If you are someone who just not good at being tested then well you have to make it up with some other skills. For example being a really2 good domain expert that the company seek for you instead of the other way around or having excellent networking(as in relationship) skills.

Re: Tech Interview Handbook

#298

Post by Consultant32452 »

DavidWoof wrote: post #275
Consultant32452 wrote: post #221

Earlier quoted context omitted.

It's not about my personal preferences. If you're concerned about an instability period on your healthcare you can literally keep you old healthcare for up to 18 months with COBRA. Adding the contract-to-hire period doesn't really impact instability, at least as far as healthcare is concerned.

I fear we've gone down a wrong turn. You may be 100% correct that fears about instability are irrational and not well-grounded, which is the point you've argued for several posts. But nobody is arguing with you. Nobody is making the contrasting argument. That simply isn't the conversation anybody is having. It's an interesting conversation, it just doesn't happen to be this conversation.

I asked what the concern was and you responded primarily in the area of health care/insurance. So that's what I addressed. What else is the conversation about if not that?

Re: Tech Interview Handbook

#299

Post by dccoolgai »

mjfisher wrote: post #273
dccoolgai wrote: post #183

Earlier quoted context omitted.

1) Resume screen 2) 30-minute coderpad/codeshare exercise on a problem/pattern you actually use/encounter during the course of your work over phone. (No inverting binary trees). Expect a 20% pass rate here. 3) Reasonable take-home problem that you've timed 2 of your own staff completing well in 50 minutes. This is where you will get the most complaints from applicants, but that's OK. Let them select themselves out of…

I'm curious about the codepad/codeshare approach right at the first touch point. I fully agree that screening actual tech skill early on is important. Do you not find that you commit a lot of engineer time to codeshare interviews that don't work out further down the line?

Another idea I've heard about but never got motivated enough to set up is a system wherein the applicant submits their resume via an api with some kind of trivial challenge... like "here is an id and an integer, multiply it by 2 and submit it with the id and your resume as a json with these fields or whatever." Might try it some day, but that's another idea to get some of the technical probe out early.

Re: Tech Interview Handbook

#300

Post by mjfisher »

dccoolgai wrote: post #296
mjfisher wrote: post #273

Earlier quoted context omitted.

I'm curious about the codepad/codeshare approach right at the first touch point. I fully agree that screening actual tech skill early on is important. Do you not find that you commit a lot of engineer time to codeshare interviews that don't work out further down the line?

Codeshare portion is 1 (typically senior) engineer for 30 minutes. Not that bad on a large enough team with everyone taking turns. I should add that we have 3-4 "canned" questions that the HR rep writes down the answer to, so even in the "resume screen" there are a few super-lightweight technical questions.

Interesting. I've got a feeling early stages of tech hiring pipelines are very poorly optimized at the minute; it's something I'm working on. Individual experiences help; thank you.
Post reply on HN