Live data from Hacker News

Lessons from 3,000 technical interviews

blog.interviewing.io

311–320 of 330 posts

Re: Lessons from 3,000 technical interviews

#311
post #305

Earlier quoted context omitted.

If your algorithm overflows counters and produces incorrect output as a result, then you don't have a correct solution. There's no way to solve the unbounded stream case correctly with finite counters as you admit . So you didn't actually present a bounded memory solution to the problem.

The number of bytes in a machine number is not the limiting factor here. You could use arbitrary precision numbers (with some constant factor of additional storage), and solve the precision problem. Being pedantic about this point doesn't get you closer to a correct answer. Read dsp1234's responses. They are correct.

They're not the limiting factor in practice, but the limit behavior of the algorithm -- how it behaves on an arbitrary length stream -- can overflow count for a fixed length counter and if you use arbitrary precision, it's no longer bounded memory. So again, you've failed to supply a memory bounded algorithm that handles the arbitrary case (but won't admit it).

Again, I'm aware of how to solve it in practice and that the problem as stated is not what you meant, I was pointing out that as stated, it didn't have a memory bounded solution.

And that it's commom for people to self-assuredly misdefine interview problems, then not understand when the interviewee points out their implicit assumption.

Re: Lessons from 3,000 technical interviews

#312
post #209

The takeaway from this is that those who do best are those with: - the wealthiest/most financially supportive parents/relatives - upbringings that are conducive to academic success - the most free time as those are the ones who, by a large margin, attend top schools, work at top companies, and have time to spend on self-learning. Another data point of confirmation of a well-studied idea. Assortative mating: http://ww…

Hypothetical question: If I could show that people who complete Coursera/Udacity courses tend to be poorer than average, would that be a "data point of dis confirmation of a well-studied idea"?

"The student population tends to be young, [already] well educated, and employed"

"The MOOC Phenomenon: Who Takes Massive Open Online Courses and Why?"

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2350964

Re: Lessons from 3,000 technical interviews

#313

Earlier quoted context omitted.

Yes, because we all know that your ability to implement a red-black tree from memory has a direct correlation with your ability to implement some random business logic or CRUD app. Oh wait, they don't.

I used to think along these lines. Then I started doing 10+ interviews a month and realized a very clear reality: basic CS knowledge and problem skills is far more important to me and my team then knowing how to slap together some semblance of a working CRUD system. I ask "algorithmic" questions, normally expressed as a legitimate business case (invent a real world problem, solution is implement some algorithm or use…

I think the key to the questions being asked at an interview is "relevance". How relevant are the interview questions to the actual job that I am applying for ? The off the hand warm up questions are fine, but in my personal experience of 18 interviews, I have not been asked a single question that I would consider relevant to the work I did/will do. Trees? yeah. Design this and that? yeah. Puzzles? you name it. Java specifics and countless Big O and Sigma questions. What about Refactoring? Nope. About designing especially for webapps? Nope. Ok, optimizing legacy code ? nope. Database structure and query optimization? Nope. Data migrations? Nope. Multithreaded support for this piece of code? Nope.

The thing is I have an arsenal of useful information and skills that I have learnt over the years that will not be asked in my next interview. I have personally been developing a list of interesting issues that I face on a day to day basis. I share it with as many people as I can some who participate actively in the interviewing process. Many do not agree with me and I do not hold them for it. I have started small and hope make a change.

Re: Lessons from 3,000 technical interviews

#314
post #289

Earlier quoted context omitted.

I so want to enroll and take the OMSCS; I know I could succeed at it if I took it, but the school requires you to have at least a Batchelor's degree to attend (they don't count work experience in software development - so my 25+ years mean nothing). I found out about the OMSCS after I started my work on Udacity's "Self-Driving Car Engineer" nanodegree course, which I am currently taking. My plan (hopefully) is after…

Western Governors University (non-profit, accredited, affordable) offers a few different B.S. programs that you could look at to use as a buffer. I received my undergraduate degree from WGU and highly recommend it. It's self-paced and there are ways to fast-track the degree in less than the typical 4 years.

Hey - thanks for this recommendation - I will definitely look into it!

Re: Lessons from 3,000 technical interviews

#315
post #232

Earlier quoted context omitted.

That's a problem with... "people looking for shiny things". There are many shiny things, and they loose their shine quite fast. It is true that many managers, recruiting agencies (almost 100%), and HR, will look for the keywords of the technologies the company is using. So if they use the new Angular 4, they will look for that. But there are companies that look for the basics: do you know javascript? Have you worked…

One thing that annoys me at present is NoSQL experience (or similar). I know enough about relational databases and NoSQL to know that unless you have a specific use case, relational is likely a better choice. If you are not scaling beyond one server, and want to view your data from different angles its almost certainly a better choice. As such I haven't really got a great deal of NoSQL experience. I will build a bett…

Interestingly, one of my 'no' signals is people relying on a DB to do the work for them. Don't know how to index this? Shove it in the DB and query it back.

If you don't have a relational query in mind a relational DB is a bad fit, or at least premature optimization.

Re: Lessons from 3,000 technical interviews

#317

The author draws a hard distinction between Udacity/Coursera MOOCs (good) and traditional master's degrees (bad). I'll interject that with Georgia Tech's Online Master's in Computer Science program [0], which is delivered via Udacity and insanely cheap [1], you can get the best of both! (Their "Computability, Complexity and Algorithms" class is one of the top Udacity courses cited in the article.) Keep in mind that a…

OMSCS looks pretty intriguing. Were there any other similar programs that came up while you were initially looking into it?

Re: Lessons from 3,000 technical interviews

#318
post #92

Until recently I worked at a startup as Machine Learning Engineer/Data Scientist. There I got some experience interviewing people and looking at their resumes. In my experience, which is very limited compared to this post, people who put an MOOC on their resume are usually less qualified compared to people who don't. There is nothing wrong with MOOCs, but they are almost always beginner-level. If you put them on your…

That's absurd. Everything in a masters degree is "beginner" when you've worked 10 years in a field. When I took my MSc in computer science, there hardly was any "big data" and deep learning around. That you actually would fail me for taking a course in this field is utterly beyond me.

I would definitely not reject you because of that and I took MOOCs myself in the past.

Re: Lessons from 3,000 technical interviews

#319
post #185

Earlier quoted context omitted.

Interviewing skill is one way you get a job. After you've been doing this for long enough, and have a reputation, you tend to just get jobs by referrals. I decided in my last change of positions to try interviewing for jobs like most people without referrals, since I had several other referral positions open. And I was horrible. I was ridiculously bad, and couldn't get a job at jobs that paid less, and were for less…

Which parts of the interviews were you really bad at? How would you change the interviews you had so they don't reject qualified candidates? I've been interviewing a lot of developers lately, and while I'm fairly happy with my process (I've managed to avoid bad hires so far), I always have to wonder if I'm turning down people I shouldn't.

The technical question part. Because I work on so many different things at the edge of innovation, I have a wide array of experience for a short period of time, and then I move on.

When I interview for jobs, I open up to any of the possible things in my background, of which it will take me perhaps 2 weeks to get back up to speed. But I am not going to take that 2 weeks for each job I interview for.

I have trained my brain to learn things, and discard them keeping only the current tasks in memory. The rest I know how to obtain again.

This means that I get asked questions I know that I've done repeatedly in the past, but can only vaguely explain without a refresher.

To the interviewer, this means I am underqualified at best, and at worst, lying about my past skills.

A lovely example of this during the process was that I was asked a fairly basic SQL question that I failed to explain when I had just landed from my second flight of the day. I didn't get the presales role for working with the database. (non referral job.)

However, I did get offered a job working on development for that database, as well as product management for the database.

So I couldn't get a presales role, that I've done in my past, because I couldn't answer a fairly basic sql question. I knew exactly how to answer it, the venn diagram of sql joins, a half second google, but in an interview, I blanked on the answer.

That is indicative of my experience with non-referral positions. I've given training on sql joins a good 30 times in my life, and couldn't explain the join in an interview.

Just the way it goes for me, thankfully it's not actually impactful in my life.

Re: Lessons from 3,000 technical interviews

#320
post #232

Earlier quoted context omitted.

One thing that annoys me at present is NoSQL experience (or similar). I know enough about relational databases and NoSQL to know that unless you have a specific use case, relational is likely a better choice. If you are not scaling beyond one server, and want to view your data from different angles its almost certainly a better choice. As such I haven't really got a great deal of NoSQL experience. I will build a bett…

Interestingly, one of my 'no' signals is people relying on a DB to do the work for them. Don't know how to index this? Shove it in the DB and query it back. If you don't have a relational query in mind a relational DB is a bad fit, or at least premature optimization.

I am not quite sure what you mean with your comment, as "relying on a DB to do the work for them" sound like a good thing to me. Its usually way faster than doing stuff in the application code, and the declarative nature of SQL usually means less bugs.
Post reply on HN