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

Lessons from 3,000 technical interviews

blog.interviewing.io

Post reply on HN
Print view View original

41–50 of 330 posts

Re: Lessons from 3,000 technical interviews

#41

Post by blowski »

dexwiz wrote: post #34
allThumbs wrote: post #21

I feel like things are operating according to the following pattern: 1. Go to college: a. spend many semesters in lectures all of which tangentially brush upon the final exam based on the whims of the lecturer. b. cram for final exam last minute panic to crunch memory according to advice on content which was brushed upon during lectures. 2. Interview for job: a. cram for interview by going to coursera to crunch memor…

Don't underestimate the knowledge gained from tangential brushes. Being able to Google and Stack-Overflow a question is dependent on knowing the vocabulary and keywords related to the problem. While tangential brushes don't give you full mastery of the domain, it gives you a bookmark on what is possible and how to find it again in the future. If you talk to newer programmers (new anything really), you will find they…

I agree with you on this. It's the difference between "I get a 500 error when I try to submit the blah form and here's the error in the log - it seems to crash in the foo method of the bar service when it receives a null value but it's not clear even from the debugger why it's getting null" vs "X doesn't work".

Re: Lessons from 3,000 technical interviews

#42

Post by JamesBarney »

geebee wrote: post #14

Interesting bit on the MS degree. I followed the link, and I'm not quite as surprised that the correlation is poor, or even negative, given the way the data was collected and analyzed. Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. However, many CS MS degrees actually do requi…

What about the way she collected and analyzed the data caused the correlation to falsely be poor or negative?

Re: Lessons from 3,000 technical interviews

#43

Post by existencebox »

vdnkh wrote: post #33
allThumbs wrote: post #21

I feel like things are operating according to the following pattern: 1. Go to college: a. spend many semesters in lectures all of which tangentially brush upon the final exam based on the whims of the lecturer. b. cram for final exam last minute panic to crunch memory according to advice on content which was brushed upon during lectures. 2. Interview for job: a. cram for interview by going to coursera to crunch memor…

> the majority of actual tasks are often googled and stack-overflowed The more I've grown as a developer the less I've had to do this.

Ah damn; and I had been doing so well mushing down my imposter complex :P

I've found the exact opposite, the longer I dev the more I look for things. I've found it entirely impractical to keep the esoterica of dozens of different languages, frameworks and tools in my head at once. What little memory I have is typically reserved for thinking about abstractions, arch/features, and core concepts, and I let myself lean heavily on lookup resources for things that don't generalize. Just today I'm writing in py+full web stack+cpp+bash+powershell+sql(both PG and ms), and using full suites of associated libs. I at the very least am entirely unable to keep all of that in my head at once, I'd be curious if you find this same problem with bringing in a wide breadth of components.

(My honest fear is that I've pushed too far to become a generalist and am sacrificing strength in depth because of this, although I am somewhat proud of the end to end results it lets me accomplish)

Re: Lessons from 3,000 technical interviews

#44

Post by frozenport »

allThumbs wrote: post #21

I feel like things are operating according to the following pattern: 1. Go to college: a. spend many semesters in lectures all of which tangentially brush upon the final exam based on the whims of the lecturer. b. cram for final exam last minute panic to crunch memory according to advice on content which was brushed upon during lectures. 2. Interview for job: a. cram for interview by going to coursera to crunch memor…

Yes, this is why we don't hire new grads. But typically when people work at a top-tier company they learn useful skills.

Re: Lessons from 3,000 technical interviews

#45

Post by allThumbs »

dexwiz wrote: post #34
allThumbs wrote: post #21

I feel like things are operating according to the following pattern: 1. Go to college: a. spend many semesters in lectures all of which tangentially brush upon the final exam based on the whims of the lecturer. b. cram for final exam last minute panic to crunch memory according to advice on content which was brushed upon during lectures. 2. Interview for job: a. cram for interview by going to coursera to crunch memor…

Don't underestimate the knowledge gained from tangential brushes. Being able to Google and Stack-Overflow a question is dependent on knowing the vocabulary and keywords related to the problem. While tangential brushes don't give you full mastery of the domain, it gives you a bookmark on what is possible and how to find it again in the future. If you talk to newer programmers (new anything really), you will find they…

Very true. I don't disagree.

At a distance, though, reality can take on funny appearances.

Re: Lessons from 3,000 technical interviews

#46

Post by vdnkh »

existencebox wrote: post #43
vdnkh wrote: post #33

Earlier quoted context omitted.

> the majority of actual tasks are often googled and stack-overflowed The more I've grown as a developer the less I've had to do this.

Ah damn; and I had been doing so well mushing down my imposter complex :P I've found the exact opposite, the longer I dev the more I look for things. I've found it entirely impractical to keep the esoterica of dozens of different languages, frameworks and tools in my head at once. What little memory I have is typically reserved for thinking about abstractions, arch/features, and core concepts, and I let myself lean h…

Yeah I suppose YMMV. I work mainly with JS on a video player which uses no frameworks. I still lean on MDN a lot and use SO for learning new things, but I've learned to rely on myself and my teammates to solve problems and where that isn't enough, to look through Git issues and documentation. I've developed my own standards of "goodness" which helps me come up with solutions. It also helps that SO does not have answers to 99% of my problems (how do I make HLS videos upswitch faster?).

Re: Lessons from 3,000 technical interviews

#47

Post by digler999 »

existencebox wrote: post #43
vdnkh wrote: post #33

Earlier quoted context omitted.

> the majority of actual tasks are often googled and stack-overflowed The more I've grown as a developer the less I've had to do this.

Ah damn; and I had been doing so well mushing down my imposter complex :P I've found the exact opposite, the longer I dev the more I look for things. I've found it entirely impractical to keep the esoterica of dozens of different languages, frameworks and tools in my head at once. What little memory I have is typically reserved for thinking about abstractions, arch/features, and core concepts, and I let myself lean h…

I back you up on this. I'm about 10 years in my career, and I use SO more and more. Because, conceptually, I know what I want to do. Last night it was trying to use the asyncio library for Python 3 to use sockets. I know what I wanted to do: async, accept, listen, read and write to sockets. But how, _specifically_, do you do that with python 3 ? Don't know and dont care. Ask SO or find someone's blog howto and be done with it. For better or worse, I dont use books at all anymore. What I find is that they take the long way to go about things. The more I learn, the more I just want to see EXAMPLES. I dont even want to read a single word "about" topic X, I just want to see topic X in use.

I'm about ready to write my own manifesto about why man pages are worthless. When I do, I'm going to blog it and submit it here. I don't even know where to start about man pages. They are reference material, but totally useless at showing you how to use the tool. even though they tell you what EVERY dash-this and dash-that option means, you can STILL screw up by not ordering them properly, forgetting a required dash-this, or not formatting the arg properly (information that is either omitted completely or buried in thousands of words inside the man page, but could be explained concisely with one simple example). the corollary is also true: examples are so effective (in my opinion) that they could go ahead and omit the "dash-this and dash-that" from the man page, and I could likely infer what those options mean just by seeing the example, or an example with a one sentence comment saying "recursively scan directories" (and I see -r). the letters often don't correlate to an actionable-thing that the tool does, the man pages don't cover the most common, useful way that tool will be used, giving equal weight (or rather, equal ambiguity) to arcane, never-used options. They take 100 words to explain what a 10-word example could show. I honestly don't recall the last time I read a man page and actually found what I needed.

Re: Lessons from 3,000 technical interviews

#48

Post by JamesBarney »

inopinatus wrote: post #15
blazespin wrote: post #4

I am perplexed why anyone would think that interview performances has any interesting statistical relevance. Much more interesting would be how successful the candidate was after receiving a job at the company.

Most hiring managers would hope that interview performance is at least partially correlated to subsequent job performance. And once experience is gained as an interviewer and team manager, it is not an unreasonable hope.

The problem is that experience isn't very useful without feedback. And managers and interviewers get so little feedback about how well they do as interviewers I would imagine they don't improve much.

Re: Lessons from 3,000 technical interviews

#49

Post by matt_wulfeck »

geebee wrote: post #14

Interesting bit on the MS degree. I followed the link, and I'm not quite as surprised that the correlation is poor, or even negative, given the way the data was collected and analyzed. Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. However, many CS MS degrees actually do requi…

> Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers.

At what point do we not consider operating systems and compilers "fundamental"? What percentage of CS/programming jobs require deep knowledge in these arenas?

Re: Lessons from 3,000 technical interviews

#50

Post by Ocerge »

blowski wrote: post #41
dexwiz wrote: post #34

Earlier quoted context omitted.

Don't underestimate the knowledge gained from tangential brushes. Being able to Google and Stack-Overflow a question is dependent on knowing the vocabulary and keywords related to the problem. While tangential brushes don't give you full mastery of the domain, it gives you a bookmark on what is possible and how to find it again in the future. If you talk to newer programmers (new anything really), you will find they…

I agree with you on this. It's the difference between "I get a 500 error when I try to submit the blah form and here's the error in the log - it seems to crash in the foo method of the bar service when it receives a null value but it's not clear even from the debugger why it's getting null" vs "X doesn't work".

This exact situations happens to me far too often, especially when working with developers who refuse to learn the other side of the stack. Had lots of "this doesn't work" conversations with frontend devs who refuse to get their arms dirty with the database, and same from backend to frontend as well.
Post reply on HN