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

231–240 of 344 posts

Re: Tech Interview Handbook

#231

Post by Jach »

bakuninsbart wrote: post #182
goatinaboat wrote: post #105

Earlier quoted context omitted.

This is just how interviewing was done in the 90s I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really k…

As a very fresh junior developer, crafting a CV is extremely exhausting, because it is very hard to gauge what you can put in. Take git as an example: I used it for a couple of personal programs, read part of the documentation, had some errors and managed to get rid of them. I know the theory of how to use it on large projects. I even know enough to know that I'm pretty much just scratching the surface, but so are pr…

Skills or tools are keyword dumps, use them as such (which in later revisions may include removing them or moving some to be contextualized in job descriptions). My own rule is to only list things I think I could adequately answer a bunch of random questions on; sometimes you might only realize you couldn't when you meet a line of questioning that totally defeats you. I don't put a proficiency level, if it's present then I'm proficient if perhaps also rusty. (Stating proficiency levels has a tendency to bring the knives out, "advanced" or "expert" begs to be challenged, and something like "mastery in C++" -- is your name Bjarne?)

> At how many lines of code can I call myself proficient in a language?

If you want a target to shoot for, I'll give you one, but don't really follow it... LoC is kind of meaningless on its own in part because it's contextual on many things (you highlighted one context, lines copied, I'll use a different context). 1k lines if paid for them, 6k-10k if not. This doesn't include lines added and then deleted (i.e. if your only project in FooLang weighs 300 lines, it's 300 lines, even if making the project involved adding 100 lines, deleting 50, adding 500 lines, deleting 100, editing 300, deleting ...) you need projects whose sum mass is 1k. Probably better to have at least one 1k+ project too, especially if it's unpaid. But again, don't follow this, it's just a somewhat random target to answer the question. Better to think about what this could be a proxy for, and target that instead.

Re: Tech Interview Handbook

#232

Post by wan23 »

DavidWoof wrote: post #11

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…

The way most fields that require some level of knowledge or ability handle this is by having industry-standard assessments that everyone takes. When doctors interview they get almost entirely behavioral questions because the hiring hospital / office merely needs to check that the doctor is a) licensed and b) certified in whatever specialty they are being hired for. They certainly never get asked whatever the medical equivalent of FizzBuzz might be.

Re: Tech Interview Handbook

#233

Post by bushido »

fogetti wrote: post #218
bushido wrote: post #213

Earlier quoted context omitted.

Why would anyone give this advice? It seems relevant to getting a tech job. If one is looking for a job, chances are that things have changed since the last time they looked for a job, which on an average for most people these days is every 2-5 years. This is not limited to engineering or tech, and extends to most specialized jobs in most industries. Can we stop handing out this advice and encourage everyone to stand…

I don't know what is a performance plan. Can you elaborate? I have never worked in a company where there was such a plan. Is this public to employees or you just simply whip everyone until they work themselves to death without telling them the reasoning? Also I assume you are in the US. In most European countries you can absolutely do nothing about someone who works full time on your team unless they let's say causes…

Performance plans, or performance improvement plans, are extremely verbose formal documents that are used as a last step to tie up all legal requirements before terminating an employee. These are most commonly used in countries outside US.

Most of the US follows At-will employment[0], so generally no performance plans are necessary.

This is not public. We've only used it twice, one person was suspected of misappropriation of funds (and later proven), and one that's currently in motion is an employee that misrepresented their technical knowledge i.e. cannot write code, convinced other employees to do 90% of their contributions.

I get that there is this impression of the US whipping everyone until they work themselves to death. Anecdotal, but I've never really experienced that. If anything, the folk in the US like being busy, and workplaces (at least in tech) are overly happy, in something that reminds me of a cult.

I have lived an worked in 5 countries in 3 continents and worked with people living in many more countries. In my own observations, the US colleagues have usually exhibited the highest level of happiness/satisfaction. They also tend to find their next jobs the quickest. And are paid the highest.

[0] https://en.wikipedia.org/wiki/At-will_employment

Re: Tech Interview Handbook

#234

Post by fogetti »

bushido wrote: post #233
fogetti wrote: post #218

Earlier quoted context omitted.

I don't know what is a performance plan. Can you elaborate? I have never worked in a company where there was such a plan. Is this public to employees or you just simply whip everyone until they work themselves to death without telling them the reasoning? Also I assume you are in the US. In most European countries you can absolutely do nothing about someone who works full time on your team unless they let's say causes…

Performance plans, or performance improvement plans, are extremely verbose formal documents that are used as a last step to tie up all legal requirements before terminating an employee. These are most commonly used in countries outside US. Most of the US follows At-will employment[0], so generally no performance plans are necessary. This is not public. We've only used it twice, one person was suspected of misappropri…

Thanks for the info. Interesting. But I assume this (i.e. the plan) is something that the employee can choose not to sign if it was not in the original contract and the law doesn't require him to do so. At least I wouldn't sign anything like that. And if he doesn't sign it then you can try firing him. Which might or might not be legal (which usually a court decides). At least that's how it works in those countries I worked in.

It's also not rare and it's actually on the news all the time all around in Europe and Japan that a company fires someone whom later the company is forced to hire back by court ruling.

Re: Tech Interview Handbook

#235

Post by nvarsj »

supercanuck wrote: post #159
jjav wrote: post #84

Earlier quoted context omitted.

I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I…

>It is, however, vital that the interviewer must be a expert in the field. This is key. There are a lot of hiring managers masquerading as experts and are frustrated when cargo culting hiring processes falter and lack the people skills to diagnose a situation. You'd also be amazed at the quality of resumes a high, advertised salary will bring.

> You'd also be amazed at the quality of resumes a high, advertised salary will bring.

This is so true. The best devs are making above market rate and are busy and content with their current role. By not including salary most of these people will simply ignore you, because of the time risk involved in finding the number. Non disclosure only works if your salary ranges are generally known (eg faang).

Re: Tech Interview Handbook

#236

Post by interviewthr »

How is this much different than a paid smaller version of LeetCode?

When I was prepping I got the most value out of LeetCode for solo prep, followed by mock interviews with sites like Pramp.com, Gianlo.co, and PracticeCodingInterview.com.

I don’t know why tech companies don’t just admit that this is all pretty much standardized at this point. Just build a standardized test, or certification, and get it over with.

Re: Tech Interview Handbook

#237

Post by rvz »

chrisseaton wrote: post #29
rvz wrote: post #2

While this is very good to study before a technical interview, over time however I can see that this alone is going to make it 40x harder to differentiate say 100 candidates that are all perfect at interviews in general, that we are going to start asking ridiculous Oxbridge-style interview questions and expect perfect scores to advance 'good' candidates. Perhaps companies will start asking candidates to construct mat…

> Perhaps companies will start asking candidates to construct mathematical proofs of data structures, algorithms Perhaps we’d produce better software if people prioritised correctness like this in practice!

Perhaps so. Those sort of questions would benefit a company working at the scale of FAANG or Microsoft and actually tackling or researching real computer science problems.

Now would this make sense for a graduate entry level role for a web / mobile app developer position? Interviewers looking for such candidates need to lower their expectations a bit in for positions like that.

Re: Tech Interview Handbook

#238

Post by twic »

new299 wrote: post #230
twic wrote: post #208

Earlier quoted context omitted.

+1. Anyone who is a programmer can solve that problem. If they can't solve it, they aren't a programmer, end of story.

So the weird thing is, that people who can’t solve these kinds of fizzbuzz type problems are often employed as programmers. And, in my experience there are definitely situations where the majority of candidates can’t solve these problems.

Right! I can think of two explanations for this.

One, these non-programmers are somehow not actually doing their jobs, but getting away with it. I've worked with people like that, but only a tiny number. Maybe i've been lucky.

Two, you don't have to be a programmer to be a developer. In this day and age, our tools, frameworks, and resources (ie Stack Overflow) are developed enough that you can actually get some useful things done without having to think mechnically. Knowing some obscure boilerplate (eg Spring annotations), how to use your IDE's autocomplete, and where to go for copy-and-pastable code for various kinds of problem actually makes you a useful team member! Even if you can't write a simple loop to save your life!

Re: Tech Interview Handbook

#239

Post by new299 »

PeterisP wrote: post #165
new299 wrote: post #160

Earlier quoted context omitted.

Do you think you could rough out an answer on a whiteboard that would have roughly the right structure? When I used this question I wasn't looking for accurate syntax. If it was a solution that looked like it would work, after some debugging etc. I'd consider that a pass. Regardless most people couldn't answer it, which I considered surprising.

Sure, the structure is obvious; one was an issue of a method being named differently than I remembered, the other was an off-by-one error that'd show up in testing.

So, it wasn’t obvious to many candidates I interviewed. For example, one candidate tried to create a solution involving 3 nested for loops.

Re: Tech Interview Handbook

#240

Post by triceratops »

_hardwaregeek wrote: post #142
triceratops wrote: post #133

Earlier quoted context omitted.

Why can't people who study to get good at algorithms also study to write better code? They've already demonstrated their aptitude for learning difficult things.

For one, interviewing requires extremely short term knowledge. Almost everybody I know who plays the interviewing game learns just enough to pass the interviews, then immediately forgets it until the next time. So it's not really comparable to learning and refining a difficult topic over the course of a few years, as in the case of software development practices. Also, it's two completely different skillsets! There's…

> Almost everybody I know who plays the interviewing game learns just enough to pass the interviews, then immediately forgets it until the next time

Presumably the first time they learned computer science fundamentals it took them some time right? People usually go to college for several years to learn this stuff - or 6-month bootcamps for 40-60 hours/week. Subsequently of course it'll take less time to refresh their knowledge.

> Also, it's two completely different skillsets! There's something very weird about interviewing for X but then demanding Y

I'm not disagreeing here. I just think most companies that use this interviewing style figure that X (easy to measure in 45-minute interviews) is a reasonable proxy for Y (much harder to measure). And Y (writing good code) is easier to train new employees to do as long as current employees maintain standards in code reviews.

Post reply on HN