Live data from Hacker News

Show HN: Free, anonymous coding interview practice

interviewing.io

171–180 of 223 posts

Re: Show HN: Free, anonymous coding interview practice

#171
post #84
post #71

Earlier quoted context omitted.

After the second interview I had an entire email written out that I was going to send to their lead, but honestly, given that the app that they asked me to develop prior to the interview was well done, detailed, commented and modern, complete with a PR flow that me and one of their devs went through via GitHub, I felt that if they were willing to pass due to me obviously locking up on a Skype + Google-Doc shared whit…

For those interviewers and candidates looking for a better solution than the "google doc shared whiteboard" - I suggest checking out a product I make: https://coderpad.io/ You can think of it as a much higher fidelity Stypi, Etherpad, Collabedit, etc, except that you can run the code in the browser as you write it . It really helps alleviate the choking sensation of being asked to write out an entire problem on a whi…

You wrote that? I love that site! I actually saw it for the first time last week when a company I was interviewing with used it as part of the interview process.

I loved how smooth and fluid it made the whole process, that they could switch between languages during the interview and the rewind functionality.

Re: Show HN: Free, anonymous coding interview practice

#172

I 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?

I personally think there's a simple answer. Give the candidate the technical questions as a take-home exercise and let them have X number of days to finish it. Probably best to have a relatively simple exercise and give them only 1 day.

Sure, some, if not most, of the candidates will use Google, Stack Overflow, their old college textbooks, or whatever will help. But they're going to do that on the job too, like most of us do. The key would be to get them to explain, in detail, how they solved the problem and why they choose their particular solution, going line by line in the code if needed.

I think this is perfect because it doesn't put the candidate on the spot. The shyest person should be able to work on their own, and I've never met a programmer so introverted that they couldn't explain the work they've already completed. The people who just faked the exercise by copy-pasting should be readily apparent once the detailed questions about their code arise.

This is probably an overly simplistic answer but I think it would make a huge difference. In the job description, make it clear this will be your interviewing style and you'll attract quite a few of the shy-but-qualified people who would probably skip Google or any of the other high-pressure interviewing companies.

Re: Show HN: Free, anonymous coding interview practice

#174
post #112

Earlier quoted context omitted.

> 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 How does that happen? Do you think they were lying about their github identities?

I can't really explain it. It was a puzzle to all of the interviewers. The only reasonable hypothesis I have where I assume the candidate was honest is that the quality of the code in his github profile is largely due to help from others.

Or that they are bad with on-the-spot-questions-with-short-time-limit-while-every-move-under-scrutiny-by-potential-employer situations ... Which usually only ever happen in interviews.

Re: Show HN: Free, anonymous coding interview practice

#175

Earlier quoted context omitted.

Right. While I wasn't interviewing for a technical position, the interviewer asked me to 'vote off' one of the 50 U.S. states, and to describe my reasoning why (perhaps this is a common question but I hadn't encountered it before). It was basically an exercise in thinking out loud, with a lot of "well, I'd probably want to first consider x, but actually before doing that I'd want to take into account y...". There was…

The answer is florida, right?

Idaho.

Re: Show HN: Free, anonymous coding interview practice

#176
post #163

Earlier quoted context omitted.

See, we're having trouble even testing for competency. I passed a pen and paper interview recently (did confidently well on coding, blew the SQL part because I had only used APIs and still thought I should put that on the resume) and still got the position. I'm still scared shitless that I'm going to flub day 1 and I've been cramming and exercising basic knowledge for the past two weeks. I'm worried that the test was…

Different people are going to have a different answer to your question, but here's how I approach things: You should commit things to memory the things your memory naturally keeps. If it doesn't it means you aren't using it often enough to bother remembering it. There's so much information I used to keep re-learning and forgetting because I never used it. I finally realized that it was a waste of time. I guess the pr…

Everything you've said is exactly what I do, and it works brilliantly for me, despite being self-taught :)

Re: Show HN: Free, anonymous coding interview practice

#177

Dear 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 underst…

The problem with these questions is the time scale in which they expect the answers. When dealing with a difficult problem, most people don't immediately come up with the right answer and adding in the pressures of an interview only makes it worse. As a development manager, I always ensure that my direct reports know all about the issues they're going to be working on at least one week in advance. I've found that the solutions they come up with are markedly better when they've had a full week of thinking time prior to writing any code.

The alternative interview technique that I like to use when hiring engineers is to send them the questions I'm going to ask a few days before the interview. I ask difficult questions, but there's no surprise. I don't really care if they talk about them with other engineers beforehand...there will always be follow-up questions that I ask to get them to defend their solution that will uncover those that haven't understood the problem fully.

Re: Show HN: Free, anonymous coding interview practice

#179

Earlier quoted context omitted.

> 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 underst…

Explaining your thought process to a coworker after you've written the code is ex post facto rationalization -- you are invariably leaving out many side-tracks, many missteps, and get to condense down a long process into a simple, seemingly obvious explanation. You already see the route, and now you're just describing it. Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring…

As someone who is very annoyed about interview process in general, I'm not sure what you think offends some people about giving them a realistic environment and time to work. What is annoying is when a false equivalence is drawn between stress and difficulty on some ad hoc interviewing task and "even a basic knowledge of skills".

Re: Show HN: Free, anonymous coding interview practice

#180

Earlier quoted context omitted.

> 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 underst…

The problem with these questions is the time scale in which they expect the answers. When dealing with a difficult problem, most people don't immediately come up with the right answer and adding in the pressures of an interview only makes it worse. As a development manager, I always ensure that my direct reports know all about the issues they're going to be working on at least one week in advance. I've found that the…

Being a person requires time to clearly think about a problem and gather thoughts I couldn't up-vote this enough. I just can't solve a problem when I know that someone is evaluating me right there and then. The way I go about it is to keep thinking about it at the back of my mind while I commute, eat, sleep etc., and then once in a while write pseudo-code or gather data to verify if a solution I'm pursuing works.

I was asked to come up with a recursive-like solution for puzzle like problem. I just froze during the interview. Later on kept thinking about it for couple of days and sure enough I was able to come up with three different solutions that used various techniques such as memoization and I felt really good about it.

I guess what I'm trying to say is it's really counterproductive to evaluate someone's abilities by subjecting them to time pressure.

Post reply on HN