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

321–330 of 330 posts

Re: Lessons from 3,000 technical interviews

#321

Post by blindhippo »

noxToken wrote: post #286
blindhippo wrote: post #273

Earlier quoted context omitted.

Resume filtering is terrible - I tend not to be involved in the process since usually recruiters or hiring managers do this. However, when someone stops by my desk and asks "should we schedule a phone screen with this candidate who lists HTML, CSS, and jQuery, as programming languages" for a senior web developer position, I say no. A huge problem is people list technologies as keywords on their resumes and rarely ind…

I know this isn't always the case, but how does one note competency in a given language or with a given tool(set) while fitting a resume on a single sheet. Especially if it's for a senior/lead or higher position? There's a lot that's broken with the hiring process. One of the toughest thing as a potential candidate is how to properly tailor a resume to fit the bill without "gaming" the hiring process. There is no sta…

My personal approach is to present myself as an individual with a large amount of skill and experience working in a specific programming discipline (e.g. web applications). I present a short list of the core tech I have experience with, ones I'm comfortable answering interview questions in. I do not list every tech I've used - that list would be half a page long and do no one any good.

I describe the projects I've worked on, what the problems challenges were, and how my work helped solve them. The format I use tends to work itself out as a simple narrative outline, and I tailor every resume to be the most relevant to the position I'm applying to, and I submit a cover letter specific to the job. This isn't "gaming" the process, this is doing your homework on the company/position and selling yourself as a viable candidate. If I'm weak in a desired skill, I call it out in the letter and demonstrate my past experience as an example of how I can learn new technologies quickly (something vital for any programmer, IMHO).

That said, after a certain level of experience, relying on your resume to get you in the door isn't going to get you the job you want in most cases. You want to meet people directly and apply via recommendations or requests. Direct contact with peers working at the company you want to apply to matters a lot. Even communication with a recruiter is better then blind submitting to a job post.

Re: Lessons from 3,000 technical interviews

#322

Post by Mister_Y »

One of the reasons I got hired by Airbnb is that I took MOOCs, but I also believe that most of my knowledge comes from reading books and that's a thing I didn't put on my CV. So, even if showing interest in learning opens for you a huge amount of opportunities, I think you actually have to go deeper than just enrolling on a couple of MOOCs.

Re: Lessons from 3,000 technical interviews

#323

Post by gaius »

Isn0gud wrote: post #223
witty_username wrote: post #216

Earlier quoted context omitted.

But it's subsidized; so people who aren't getting an education are paying for those who do.

One could very much argue that having educated people is more beneficial to the society, and therefore for everyone, than it costs the society. Also educated pay more taxes individually since they usually earn more.

But you'd have to argue it, it isn't self-evident that more education is simply better. Look at the number of PhDs who can't secure post-docs let alone tenure track. They may feel some personal satisfaction from the letters after their names, but it's very questionable that "society" benefits from churning them out. Once you educate people to the level of basic literacy and numeracy, say age 16, it's diminishing returns after that.

Re: Lessons from 3,000 technical interviews

#324

Post by blindhippo »

manishyt wrote: post #308
blindhippo wrote: post #271

Earlier quoted context omitted.

That's more advanced then the question I ask typically. Though I might use something like this if I'm interviewing someone with many years of experience (10+). As I explained above, my question is a warm up - meant to break the ice, calm nerves. But it's surprising to me how effective even a simple list traversal is at identifying weaknesses in a candidates programming ability.

Just out of curiosity: how would you feel if I answered this question by using existing function [1] in stdlib? Would you consider that as (good) sign of knowing the tools or would you prefer a fresh implementation? [1] https://docs.python.org/2/library/itertools.html#itertools.c...

I see it as a positive if a candidate uses an existing solution to the problem. That's exactly what a good engineer would do in the real world.

But then I take away the library/method and re-state the problem. Because the point is to see if they can understand the problem, and devise a solution.

Re: Lessons from 3,000 technical interviews

#325

Post by blindhippo »

jcadam wrote: post #309
blindhippo wrote: post #271

Earlier quoted context omitted.

That's more advanced then the question I ask typically. Though I might use something like this if I'm interviewing someone with many years of experience (10+). As I explained above, my question is a warm up - meant to break the ice, calm nerves. But it's surprising to me how effective even a simple list traversal is at identifying weaknesses in a candidates programming ability.

Heh, at my previous employer the only coding question we asked during interviews was: "Find the largest element in an array of integers." Some of the ways people found to not solve that simple problem were amazing. Now, I'm generally against asking hard-core CS questions in a live interview... but a simple bozo filter is probably a good idea.

It really does surprise me how a simple programming questions like this does stump the average interviewee. If they need a bit of guidance to get started, I never hold it against the candidate, but if they need a massive hand holding to come to a solution, or if they can't explain how their solution works and how it could be improved, then I know where they stand programming wise.

It is a low bar skills wise, and it tells a lot within a very short amount of time.

Re: Lessons from 3,000 technical interviews

#326

Post by AmitJS »

dsp1234 wrote: post #304
SomeStupidPoint wrote: post #299

Earlier quoted context omitted.

You can't have finite counters per word, else you can't disambiguate between counter length of a single word then the pattern I described and just the pattern I described, despite the fact it impacts the answer. Your solution is incorrect because it fails to handle arbitrary length streams as specified -- as do the other glib answers. My point was the specification didn't seem to align with the intended problem, and…

You can't have finite counters per word You only need one counter per word. a quick sketch of the basic algorithm is: 1.) Create a new list of type into COUNTS 2.) Read a word from the stream into WORD 3.) if WORD exists in COUNTS, then increment the number for that entry 4.) if WORD does not exist in COUNTS, then add WORD to COUNTS with a number of 1 5.) if not end of stream, goto 2 6.) traverse through COUNTS keepi…

Hash tables FTW!

Re: Lessons from 3,000 technical interviews

#327

Post by manishyt »

blindhippo wrote: post #324
manishyt wrote: post #308

Earlier quoted context omitted.

Just out of curiosity: how would you feel if I answered this question by using existing function [1] in stdlib? Would you consider that as (good) sign of knowing the tools or would you prefer a fresh implementation? [1] https://docs.python.org/2/library/itertools.html#itertools.c...

I see it as a positive if a candidate uses an existing solution to the problem. That's exactly what a good engineer would do in the real world. But then I take away the library/method and re-state the problem. Because the point is to see if they can understand the problem, and devise a solution.

Cool. Thanks for your comments.

Re: Lessons from 3,000 technical interviews

#329

Post by EdHominem »

collyw wrote: post #320
EdHominem wrote: post #315

Earlier quoted context omitted.

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.

> I am not quite sure what you mean with your comment, as "relying on a DB to do the work for them"

Maybe "to do the thinking for them" would be more accurate.

> sound like a good thing to me.

You did what they do - you assumed based on some your usual workloads that a DB and the overhead of using another language, and a non-compile-time checked language, with poor integration (type mismatch), is the solution for the problem I'm working on.

What I expect them to do is ask questions. How many values are there? Are they complex types or something that would map to tables well? What are the querying requirements? Are there any relational elements to the data?

> Its usually way faster than doing stuff in the application code

If shoving things across two sets of pipes, to a general-purpose app not tuned to your workload, is faster - you're writing your main app incorrectly.

> the declarative nature of SQL usually means less bugs.

A declarative language usually means less bugs. But adding a second mismatched language usually means more. Especially when it comes with a whole new system that takes experts to properly tweak.

Re: Lessons from 3,000 technical interviews

#330

Post by [deleted] »

AndyNemmity wrote: post #169
Apocryphon wrote: post #98

Not to harp on the "technical interviews are disconnected from actual work!" angle too much, but I'm reminded of a comment from a thread about the creator of Homebrew failing a Google interview. Someone pointed out that it goes to show that it's possible to create widely-used software without an intimate knowledge of CS. I wonder if that's a disconcerting fact for some employers to grapple with.

Made a similar comment above, but that was entirely true for myself. I have worked on amazing things as we all have in life, petabyte databases, and just the most incredible setups. But when it comes to an interview, I cannot get a job several levels below my own (without referrals). With referrals, I am offered the moon and the stars, complete pick out of a tremendous number of amazing jobs. But any random interview…

[deleted]
Post reply on HN