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

Code Interviews

alaiacano.github.io

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Code Interviews

#71

Post by yodsanklai »

b20000 wrote: post #63
yodsanklai wrote: post #27

Earlier quoted context omitted.

> you should be able to get enough evidence from their resume / github / references The problem is when you get 1000s of such resumes, but only a few positions to fill. Also, not everybody has time to spent on github projects. It can be even more time consuming to work on personal projects than brushing up your algorithmic skills. Not saying these interviews are perfect, but I do believe that they are a good solution…

if I spend 3 months full time building a product, I have something of value, guaranteed. If I spend 3 months on interview prep, then I still have to start going through the cycles, and it will take another 3 months before I might have a job. No guarantees. Anyone can build something in a month, so the idea you have no time to build a side project is just BS. Especially if you can spend months grinding leetcode.

It's a gamble. Most companies don't bother to look at Github page, at least in my experience. On the other hand, the skills you build grinding leetcode can get you a good job (and the next ones).

Re: Code Interviews

#72

Post by toddm »

As a data scientist, I regularly get asked at least a subset of questions that are more suited for real software engineers. Very few interviewers get around to asking relevant things (for me/my job).

My day-to-day is messing around with pandas and matplotlib, mostly, but I never get interviewed on that. It's usually brainteasers, time complexity of some algorithm, and an invariably-rigged machine learning thing I can never get right.

Re: Code Interviews

#73

Post by Zababa »

b20000 wrote: post #65
Zababa wrote: post #57

Earlier quoted context omitted.

Why? People lie a lot about their skills. The fizzbuzz test was invented a first to filter candidates that said they knew how to code but didn't, and it was very effective at it.

Being able to write software does not automatically imply you are able to write software while on a video call, and while explaining what you are doing constantly.

True, this approach will cause false negatives. But from what I understand, most people in interviewing prefer false negatives to false positives.

Re: Code Interviews

#74

Post by a_square_peg »

seanmcdirmid wrote: post #34
ryanbrunner wrote: post #24

Earlier quoted context omitted.

Doesn't it seem like an absurd scenario to you though, that you need to prep for an interview by relearning skills that aren't relevant to the job you're interviewing for? I've been in coding interviews that matched the work that the company is doing, and I've found those useful - I get something from taking the interview (an idea of what their codebase is like, working with a partner, maybe some interesting code des…

It is absurd, but is so easy to counteract by just prepping. I’d be a lot more negative about it if it wasn’t so easy to game.

I think this is the point - that it's so easy to game (albeit a waste of time) and that this doesn't reflect on the quality of the hire coming through this process. Assuming this is the test for senior engineer, the greatest candidacy pool would be second-year CS students.

Re: Code Interviews

#75

Post by b20000 »

___luigi wrote: post #70
_skhan_ wrote: post #32

Earlier quoted context omitted.

You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…

> .. I see have almost zero history of contributing to OSS or maintaining side projects. Not sure about US, but in EU, the contract from employers doesn't allow you to contribute code without permission (e.g. contributing to OSS, working on side projects, etc), it's very very rare to find an exception. You can check this discussion few weeks ago: https://news.ycombinator.com/item?id=27843198 > I have to rely on that…

I never heard of that. I'm originally from the EU and in the country I'm from, employers cannot control what you do in your spare time, and do not automatically own what you do outside your day job. In the US that's much more complicated.

Re: Code Interviews

#76

Post by ChrisMarshallNY »

___luigi wrote: post #70
_skhan_ wrote: post #32

Earlier quoted context omitted.

You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…

> .. I see have almost zero history of contributing to OSS or maintaining side projects. Not sure about US, but in EU, the contract from employers doesn't allow you to contribute code without permission (e.g. contributing to OSS, working on side projects, etc), it's very very rare to find an exception. You can check this discussion few weeks ago: https://news.ycombinator.com/item?id=27843198 > I have to rely on that…

Very good point. Depends on the company.

I was fortunate, in that I didn't have a "shower clause" in my employment contract, so I was able to do a lot of extracurricular work.

In fact, it was a principal reason that I stayed at that company. They paid me...OK...for doing the work I hated (managing -but I was also a good manager), and let me have enough bandwidth to do my extracurricular work; which was my true passion.

Basically, the work I didn't get paid for, was what I really wanted to do. They were extremely happy with the work I did for them, which did not reflect my true, personal passion. I feel like I was "just going through the motions," as a manager.

But I also firmly believe that if I am given responsibility for a task, then I do it to the very best of my ability; whether or not I am passionate about it, and I'm actually a really decent manager (for the type of team I led).

After leaving that company, and learning (the hard way) that no one wants to work with a 55-year-old engineer, willing to work at half the wages of far less-qualified people (because I already had my retirement set), I was forced into early retirement, and actually achieved my dream, which is writing code to help out NPOs, for free.

Re: Code Interviews

#77

Post by b20000 »

Zababa wrote: post #73
b20000 wrote: post #65

Earlier quoted context omitted.

Being able to write software does not automatically imply you are able to write software while on a video call, and while explaining what you are doing constantly.

True, this approach will cause false negatives. But from what I understand, most people in interviewing prefer false negatives to false positives.

Sure, they can go right ahead and keep preferring to pass on exceptional people and hire mediocre people instead who will entertain their circus. Sooner or later they'll find out that won't work so well to stay competitive.

Re: Code Interviews

#78

Post by b20000 »

yodsanklai wrote: post #71
b20000 wrote: post #63

Earlier quoted context omitted.

if I spend 3 months full time building a product, I have something of value, guaranteed. If I spend 3 months on interview prep, then I still have to start going through the cycles, and it will take another 3 months before I might have a job. No guarantees. Anyone can build something in a month, so the idea you have no time to build a side project is just BS. Especially if you can spend months grinding leetcode.

It's a gamble. Most companies don't bother to look at Github page, at least in my experience. On the other hand, the skills you build grinding leetcode can get you a good job (and the next ones).

grinding leetcode guarantees nothing. I does not guarantee you will get a job now, and it won't in the future when you go looking for your next job. Looking back at my recent experience I don't see how it made any sense for me to spend my time on that.

Re: Code Interviews

#79

Post by Zababa »

b20000 wrote: post #77
Zababa wrote: post #73

Earlier quoted context omitted.

True, this approach will cause false negatives. But from what I understand, most people in interviewing prefer false negatives to false positives.

Sure, they can go right ahead and keep preferring to pass on exceptional people and hire mediocre people instead who will entertain their circus. Sooner or later they'll find out that won't work so well to stay competitive.

> keep preferring to pass on exceptional people and hire mediocre people instead who will entertain their circus

That's what big companies are all about, there's really nothing new to see here. It seem to be working well for most of them though.

Re: Code Interviews

#80

Post by ozim »

b20000 wrote: post #64
ozim wrote: post #54

Earlier quoted context omitted.

It is like a cover letter, if you will do half-arsed one it will work against you. It has to be a good CRUD kitchen recipe app if you want to show it off.

A cover letter won't tell you whether the candidate can get anything done. A small coding project will.

I am not writing anything about small coding project vs cover letter. Tool that I used in my comment is comparison to show common traits of both ... like "white as snow".

Bad - small coding project will show that candidate is a bad coder, even if the code works.

Bad - cover letter will show that candidate has bad grammar, even if person put in the effort.

Good - small coding project will show that candidate can get anything done.

Good - cover letter will show that candidate is willing to put extra effort to get the job.

Post reply on HN