Live data from Hacker News

How I Interview

rkoutnik.com

111–120 of 129 posts

Re: How I Interview

#111
post #73
post #59

Earlier quoted context omitted.

> Am I the only one who, when being interviewed, doesn't mind whiteboard coding? I'm sure you're not, but my experience is completely opposite of yours. I'm still relatively early on in my career (I've had 3 software jobs, but have grown up coding since I was 12), but every job I scored was one that didn't use a whiteboard/paper problem during an interview. I got a lot better at whiteboards with practice; but early o…

Whiteboarding is a skill that the vast majority of people will have to work to obtain. It's not the natural way that we work. Personally, if you know you're going to be interviewing, start practicing for whiteboarding. There are books and online resources available to help you get at least comfortable with it. The resources also help drive home that whiteboarding should be about process, not about perfect solutions.…

Do that many places ask you to perfect an algorithm or solution? Most places me and my friends have done typically just want any brute force solution with some discussion as potential ways one might improve or discussion on why this might not be ideal without having better ideas. And this is from top places and offers. And were from non top schools.

Re: How I Interview

#112
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

This is why I prefer dating contracts to deep technical interviews. If someone shows enough promise in their CV and portfolio, and they're personable enough to sell themselves reasonably, then a 1-2 week contract to cover some real work is low risk and a better measure than trivial whiteboard problems.

Re: How I Interview

#113
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

Your approach seems sensible as a freelancer. Hope it works out for you! But I don't think it would work for someone who's full-time employed looking for another full-time employer: 1. People can't just take two weeks off to go code for another company. 2. With so many other candidates out there, a company is typically not going to bother with an "eccentric" who refuses to interview. (not saying you are eccentric, ju…

Two way street... assuming the guy was legit and confident, he'd have other offers lined up, and your company may have been the loser.

I for one commend "whiteboard refusers."

Re: How I Interview

#114
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

You grossly underestimate how conservative and risk averse most clients are. As a consultant I have tried a variation on your approach. I've offered to work for a client for 2-3 weeks. At the end of which THEY get to decide how much I'm worth. I reserve the right not to carry on working for them but for those 2-3 weeks I will accept whatever they pay including nothing. In over a decade not one client has accepted thi…

Dunno, not sure this applies. My reaction would be that it is too much to think about. I'd just want to pay a certain rate and be done with it, not load up on ambiguous ill-will.

Now, the GP says he will work first two weeks without pay? Simple to understand and accept.

Re: How I Interview

#115
post #79
post #70

Earlier quoted context omitted.

That sounds like a sensible way to work as a freelancer. Have you already had success with it or is it just a plan for the future for now? I'd be interested in hearing how it pans/panned out.

Well, yes and no. For around 3 years, I have been running my own consulting company with a friend. We were doing pretty much what I do as a 'solo' consultant, except that we were fronted by a company. This automatically removed the need for interviews. As soon as I sold my company and got back to solo consulting, I had to re-enter into this ridiculous circus which are technical interviews. So, to answer your question…

[deleted]

Re: How I Interview

#116
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

I can't upvote this enough. In the age of Github, if a candidate has an impressive body of work and can "talk the talk", a coding interview is wasteful, potentially misleading and insulting. As soon as enough candidates balk at them, companies will stop doing them.

Re: How I Interview

#117
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

> Why shall I still prove myself? Because we see candidates claiming that level of experience that cannot construct a simple for loop.

I assume you're exaggerating slightly and that you mean "couldn't code as well as the resume suggested". How certain are you that the pressure of the interview (which often means broken concentration, poor sleep the night before, etc) and the unfamiliarity of the setting (even typing in a Google doc without proper spacing, syntax highlighting and auto completion can be incredibly disorienting) aren't a major factor? Isn't it conceivable that some worse coders are better under such circumstances than a great coder who suffers mightily under them?

Re: How I Interview

#118
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

> Why shall I still prove myself? Because we see candidates claiming that level of experience that cannot construct a simple for loop.

This. We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer, who can't explain the difference between a list and a vector (or when to use each), or give even a ballpark estimate for search/insert/remove times for a basic BST. At the same time, there are candidates who are technically good at coding, but terrible problem solvers. We do use whiteboards for the interview, but more as a conversation starter for the algorithmic design, and don't expect compile-able code. In fact, when I interviewed here a year ago, I didn't touch the whiteboard, and we just talked about the design, tradeoffs, wrinkles/edge cases, etc.

It is usually a pretty organic process. If we get into it and question their coding ability, we might ask a few basic questions, like how do you declare an array or vector in C++. Do you use std::algorithm? Then possibly into C++14 territory. It depends on the position. On the other hand, if they breeze through some basic coding questions, it quickly turns into a discussion and feeling the candidate out in terms of fit. But if we get a senior SE come in, and we talk about previous projects and we get "I fixed bugs, reduced memory usage, and saved $X million dollars" that is a big red flag.

Re: How I Interview

#119
post #80

Earlier quoted context omitted.

> Why shall I still prove myself? Because we see candidates claiming that level of experience that cannot construct a simple for loop.

Well claiming is a very far galaxy from "demonstrating". What about references? What about networking? What about published books and papers. This stuff is very hard to make up, especially references.

It can be a chicken and the egg problem. None of those matter if the person can code and solve problems, and is a good fit. We don't care if they are 15 or 60 years old.

Re: How I Interview

#120

Earlier quoted context omitted.

Your approach seems sensible as a freelancer. Hope it works out for you! But I don't think it would work for someone who's full-time employed looking for another full-time employer: 1. People can't just take two weeks off to go code for another company. 2. With so many other candidates out there, a company is typically not going to bother with an "eccentric" who refuses to interview. (not saying you are eccentric, ju…

Two way street... assuming the guy was legit and confident, he'd have other offers lined up, and your company may have been the loser. I for one commend "whiteboard refusers."

Maybe so. We use whiteboarding as a jumping off point for discussion, not to implement trees or graph traversals. It is usually apparent within a few minutes if the candidate knows their stuff, and we move deeper. Additionally, there is always going to be an onboarding period, where the new hire is learning how our team does things. We spend a lot of time communicating and drawing out ideas on whiteboards. We need to see if you can communicate clearly. Saying "naa, I don't whiteboard" is NOT a good start. In all likelihood this person would be a bad fit.
Post reply on HN