It's like Chatroulette[1] for technical interviews. [1] But without the dicks I laughed at this...
I came here to say just that! :D
Show HN: Free, anonymous coding interview practice
131–140 of 223 posts
Re: Show HN: Free, anonymous coding interview practice
#132Earlier quoted context omitted.
People are very diverse, some are fast and chatty, others are quiet and slow. Usually I perceive the fast and chatty types a bit arrogant. Personality and cultural background is probably an influence. Best teams have a great mix. Often caring about the work is more important than having a genius. (Of course people should be competent).
I do coding interviews exclusively since I find whiteboard interviews even more artificial. I try to match the interview to a persons skill set and ask them to implement things they should know or know how to look up if their resume isn't a lie. I don't care if they talk or not while doing the interview and I take the role of a product designer who doesn't know how to code. If they get interview anxiety I give them t…
I think that what you do makes sense if you take the time to read the resume, code samples, articles, and ask relevant questions. Asking to write some code is perfectly fine to see how the person works. References are also very important for more experienced candidates with a track record.
Re: Show HN: Free, anonymous coding interview practice
#133Earlier quoted context omitted.
>I have plenty of open source code, if they cannot figure how good I am looking at... I've interviewed several people with lots of code on github and what looks like lots of accepted pull requests to many projects who still can't seem to reason through a problem described as "write a function that takes two unsorted lists and returns one sorted list". I think I'll continue asking technical/coding questions...
What is the correct answer to this? Let's try a little experiment.. I've never heard this question before, so I'm in the same boat as a naive interviewer right now. Let me elaborate my thought process. "H'm, this looks a bit like mergesort, where you take two sorted sublists and form a bigger sorted list. So...sort the sublists using mergesort, then call the merging algorithm? (compare the heads of the two lists, and…
We try very hard to NOT ask questions that have only one correct answer, and my team only interviews/hires senior people. So my approach to interviewing might be different than someone who's interviewing a fresh grad.
I treat all questions as conversational. The direction the question goes depends on where I (or other prior interviewers) think more evidence is needed.
For example: merge sort is an answer that satisfies the conditions of the problem. Given that, I would decide if I need more evidence about your ability to code, if so I'd ask you to implement merge sort; I might want more evidence on how you explain things, so I would pretend that I didn't know what merge sort was and ask you to give me a description of it.
Re: Show HN: Free, anonymous coding interview practice
#134Dear software professional: if you have been rejected because of a coding interview, don't feel bad or discouraged. It has little to do with how smart you are. Unfortunately, this style of interviews is likely ineffective and leads to hiring people who look alike and have similar skills. Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that…
"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking" is actually how problems are generally solved in most fields. Software engineering is perhaps one of the lone exceptions, and I think the pair programming movement has a bone or two to pick with your premise.
There's a big difference between someone looking over your shoulder and forcing you to explain what you're thinking, and someone working with you to collaboratively solve problems. In the latter case, you can ask lots of questions and throw out lots of dumb half-baked ideas, and actually get a meaningful, useful response from your partner/pair in response. If you're whiteboard interviewing, good luck getting your interviewer to meaningfully engage with you, since they don't want to "give away the answer".
The best interviews I've had were legitimate pairing interviews, where the two of us were tasked with solving a problem in a real codebase that the interviewer hadn't solved before.
(The best best interviews made it an issue in an open source project, so it can be a not-canned interview without you writing potentially production-ready code for a for-profit company without being paid)
Re: Show HN: Free, anonymous coding interview practice
#135I find code interviewing so nerve-wracking that I'm delaying my transition from another profession into a much-desired full-time programming job. I'm 40 and always aced interviews before I did my first coding interview last year. In my prior career, I literally never had an interview that failed to result in an offer. But I blew my first coding interview both in the interview itself -- in which I repeatedly blanked o…
Thank you so much for sharing this. Look at it this way, many companies are missing great talent because of their interviewing practices and for trying to imitate Google or Microsoft. More innovative companies (think Moneyball) can take advantage of this pool of talent and target people like you. I'm trying to think how to make it easier to identify this talent. Any ideas?
Re: Show HN: Free, anonymous coding interview practice
#136Earlier quoted context omitted.
The analogy I use is a coding interview is like asking a musician to play a specific song; chances are, a classically trained pianist won't know the chords to a specific pop song, but that isn't any indication of their skill as a musician. The interviews I had with the company I work for now were amazing; they asked me some basic questions to verify my resume wasn't completely BS, then asked me to discuss previous pr…
I recently was flown to Austin for an interview. The entire reason I was brought down was because of Python ML projects on Github. The technical interview consisted of nothing, and I mean NOTHING but super advanced SQL questions. (over the phone, I had specifically stated I hadn't used SQL in years) My expectation was that I'd be interviewed using Python and asked to perform ML related tasks. When I mentioned that I…
Maybe if I am in a similar position, I should demand compensation for my time. That way I'll at least get to visit friends and see scenery around Austin. I wonder if a demand for compensation (besides airfare and stuff) would fly...
Re: Show HN: Free, anonymous coding interview practice
#137Is there a business model here? Why are the talented engineers running the practice interviews devoting time to this?
I'm guessing because there is potential they could find a hire. Even though you can choose to be anonymous, if two people hit it off there is nothing preventing them from exchanging contact info. Seems like somewhat long odds unless the candidate is willing to relocate anywhere.
Re: Show HN: Free, anonymous coding interview practice
#138Earlier quoted context omitted.
Dude, if you're that passionate about that job you just described then I'd suggest calling the company up and explaining what happened. Having interviewed many people I'd certainly be open to giving someone a second chance if they explained a situation like yours to me.
I blew a technical phone screen with Zynga and not only did the interviewer not respond to any of my follow ups, the in house recruiter actually blocked my calls. Radio silence seems to be fairly standard after deciding to reject a candidate.
It's also Zynga, though. They've gotten flak before for not being the most considerate toward their employees. Maybe that attitude extends to candidates as well?
Re: Show HN: Free, anonymous coding interview practice
#139Dear software professional: if you have been rejected because of a coding interview, don't feel bad or discouraged. It has little to do with how smart you are. Unfortunately, this style of interviews is likely ineffective and leads to hiring people who look alike and have similar skills. Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that…
>forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world
You've never once explained your thought process to a coworker? Explained how you arrived at a conclusion? Tried to elucidate your reasoning on a piece of code to someone?
These are absolutely real world skills and they are absolutely applicable when working on an engineering team with other humans. I understand what you're getting at in your comment, but it really feels like you're throwing out the baby with the bathwater. Can interviews be improved? Absolutely. Does that mean that there is no value in these kinds of interviews? I certainly seem to glean some value out of them. Whether that is the right value is a hard question to answer.
But I want to address something. Your whole comment is about why these kinds of interviews are shit. But you offer no alternative methods, no ways to improve these kinds of interviews, and really no constructiveness. You seem so sure that interviewing this way is wrong, but you don't say what's right. I would love to hear some realistic ways to interview people that can help me find better candidates without rejecting people because they're bad under pressure.
Re: Show HN: Free, anonymous coding interview practice
#140Earlier quoted context omitted.
People are very diverse, some are fast and chatty, others are quiet and slow. Usually I perceive the fast and chatty types a bit arrogant. Personality and cultural background is probably an influence. Best teams have a great mix. Often caring about the work is more important than having a genius. (Of course people should be competent).
I do coding interviews exclusively since I find whiteboard interviews even more artificial. I try to match the interview to a persons skill set and ask them to implement things they should know or know how to look up if their resume isn't a lie. I don't care if they talk or not while doing the interview and I take the role of a product designer who doesn't know how to code. If they get interview anxiety I give them t…
What else can you do that would be an accurate simulation of their job that only takes 1hr?
First 1/2 hour: Discuss their code samples in detail -- asking pertinent questions about each as to what they do, and why they did things they way they did. Drill down for detail, ask how they might have done things differently for different use cases, etc.
Second 1/2 hour: Bring out some of your own production code and do the same (allowing them space to ask questions this time). Works best if you let them see something that's a bit "raw", i.e. quick and dirty, which you know you could have done a lot better if you had more time or knew better about the requirements (or perhaps you're simply older and wiser now).
In both sessions, nuance (both in what they can observe, and how they chose to express themselves) is key. And it'll come out a lot more freely than in in a whiteboard interrogation precisely because they interaction will be natural, uncontrived and unforced.
Simple, non-confrontational and 100% reflective of what engineering work is like. That's what we do during the day, 99% of the time -- digging up (sometimes woefully) less-than-perfect components of production systems, and trying to make them a little bit better.
But as to how often we drag someone to a conference room, throw them at a smudgey whiteboard with creaky pens and no eraser, and force them to solve some abstract problems while we boredly look at our watch, and interrupt them with hints?
Basically never. Except, that is, in coding interviews.