Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You are trying to measure what?

I'm going to assume your answer is "on the job performance". If not, this is going to be a difficult conversation, and I'd ask why you are trying to measure for something you aren't going to be paying for.

The best predictor of on the job performance is ... on the job performance. Everyone but the most junior person has experience. Look at that.

All of these exam type questions usually rely on knowing a trick, or being recently well versed. I TA'd a graduate course in Algorithms. That's rather relevant, I would think, since you aren't offered that if you don't have ability. Yet you know the last time I've done, say, dynamic programming? It's been awhile. I know about it, I know when to decide whether to pull it out, but ask me to do it, in a high pressure interview (all interviews are high pressure), and well, I'll probably fail. I'm working on other things like Bayesian inference. Bet you'd fail doing that stuff, even though it is just simple multiplications and such, when you get down to the implementation. Unless, of course, you are working on that sort of stuff right now.

I find the situation in SV somewhat ridiculous. To go out and interview means a lot of prep. Google recommends spending a month reviewing algorithms before applying. You know, I have an actual job, and I have open source side projects, and I have a family, and hobbies, and an old dog I want to spend all my time with. It is trivial to find out my skills by looking at what I have done and asking me questions about it. Have me give you a 1-2 hour tech talk, for example (I like public speaking, most don't so that is not a universal solution). Have me write some code with you, if you must. I work at a very high level, but I am not necessarily 'clever' at seeing the right trick in 10 seconds under pressure in an interview.

Also, how important is that sort of thing, really? For some jobs it is, undoubtedly. If you want me to write a load balancer for your cloud infrastructure, there are some algorithms I need to understand. Even then, not knowing something now is not evidence I can't do the job. I can learn - it's how I've done everything up to now. I can learn your thing too. More importantly (to my mind) - am I a hard worker? Can I mentor others? Can I lead a team? Can I put a schedule together, and recognize when that is appropriate and not appropriate? Can I make a budget? Can I talk to clients? Do I meet my deadlines? Do I solve problems - not implement the cards in this sprint - but see friction of some sort at work and engineer a solution? Do my peers like working with me? Do I get shit done? Is my code maintainable, readable, modular, commented? Can I write? Can I teach? Can I work with the CEO?

I've been to so many interviews where they don't even try to learn any of that latter stuff, where they show no interest in what I have done, where they don't try to figure out if I can do the actual job they are doing, but are deeply interested in if I can program a smart pointer, from scratch, to some arbitrary set of requirements. It is all just deeply puzzling to me.



I understand what you mean about ridiculous SV interview practices. And your point that all we should really be measuring is on the job performance is an important one.

All I'm really going for is to ask someone to write some code live, on their laptop with their tools, so I can watch how they debug, how they think through things, etc. I want the problem to be hard enough that the person has to model execution in their head and that it's challenging to do so.

I have found that there are people who can code decently well but get badly stuck when the complexity hits a certain level. I'm trying to not hire them in senior positions.

For example, I had a recent project where we were analyzing user data and producing a bunch of edges representing potential connections detected between users, as a way of sniffing out fraud rings.

One feature associated with this was a banning UI, allowing loss prevention types to navigate through the graph, select groups of users according to certain criteria, and generally look for patterns that are evidence of fraud rings manually, to supplement the automatically generated analysis.

There are a lot of front end people who will go into brainlock on this kind of thing. I need to make sure I have some people around who don't.

When making senior hires, I want people who can write code for this sort of thing without making a huge mess or just getting stuck for weeks.

Presenting a real sample from a problem like this needs way too much context though.

I'm going to keep thinking about how to precisely define the type of task that i'm really talking about here. My fuzzy definition about ability to model execution of X complexity in one's head is obviously weak and probably flat out wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: