4 ms·

> I think it is more than just being underpaid. Doctors, dentists and lawyers do not have to go through such stupid recruiting processes. I've known people to g

by eshvk 13y ago

> I think it is more than just being underpaid. Doctors, dentists and lawyers do not have to go through such stupid recruiting processes. I've known people to get hired in 15-20 minutes. The assumption is that your education and previous work experience is worth something. This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason. > Here's an idea: hire smart people. Even if they don't know your particular stack. What the fuck does smart even mean anyway? How do you find out in the space of 5 one hour interviews if a person is smart or not? 1. If smart means problem solving ability, the way we test it now is a huge crock of shit because it is hard to abstract out domain specific elements from pure problem solving. I mean if you take any Math olympiad book, there are no pure problems beyond the puzzle level, most of them have a few tools of the trade that you can use. I remember someone posting here that IQ tests are illegal and probably not very good. 2. If smart means suave, sophisticated or looks like me (the accepted buzzword is "cultural fit"), it is going to not scale very well.

RBerenguel 13y ago
I've always thought that (in regard with most tasks) being smart would be another way to putting "gets sh*t done." I'm by no means a great programmer (I'm a mathematician and could only stand a CS degree for around a year before deciding most of it was boring and I'd rather get into the interesting stuff on my own) but I can get things done. Sometimes the code is ugly, I forget to add test coverage (or god forbid, error checking!) or it is unnecessarily convoluted. But on the end of the day, it's doing its job. It can be refined later on, and each error check/test coverage problem/non-idiomatic language feature I forget is a lesson for the next project in the same language/stack. I'm smart? Yeah, think so, at least with this narrow-minded definition. In other aspects, I'm not (like when confronted with these interview-like puzzles: I've always hated them, even as math gimmicks.)
- eshvk 13y ago
  See this is where it gets into the realm of being subjective. I used to think that getting shit done was the only prime directive that matter. Until, one fine day I found myself given legacy code written in PHP by some dude who hadn't been in the company for years and years. Suppose you had come by my table during that dark and painful period and asked me if I would hire the dude, I would probably have said no, god no. On the flip side, there is a tradeoff. You can't realistically expect to ship if you expect every module to be pretty as fuck. Again, this is also something you realize with more experience? Are you then smarter? This is kind of getting into theory of the mind territory here.
  - redblacktree 13y ago
    As with all things, it's a trade-off, and there is a balance somewhere in the middle. i.e. Don't do really dumb things like copy-pasting code everywhere, but also don't feel that every line of code must be a masterpiece. There isn't one rule or paradigm for all situations; you just have to use your best judgment.
  - RBerenguel 13y ago
    As redblackthree says below, there's some leeway in there. I guess it comes down to knowing what tradeoffs are you doing to get it done sooner. In my case I usually know where I've done some cheapish job and mark the code area with a "FIX: explanation of what should be done" for when I have time for that. I also eventually come back and clean up whatever code mess I got, or at least comment the mess so it doesn't come biting back at me in the future.
munin 13y ago
> This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason. this has not been my experience, lab / academic jobs are a day of interviews which probably will not have any programming questions because you're hiring a scientist, not a staff programmer, but you will talk about research, ideas, and be expected to think and produce insights on the spot, and you as a candidate will give an hourlong talk. the decision is not made before you show up and the desires of the hiring body are very fickle.

by eshvk 13y ago

RBerenguel 13y ago

I've always thought that (in regard with most tasks) being smart would be another way to putting "gets sh*t done." I'm by no means a great programmer (I'm a mathematician and could only stand a CS degree for around a year before deciding most of it was boring and I'd rather get into the interesting stuff on my own) but I can get things done. Sometimes the code is ugly, I forget to add test coverage (or god forbid, error checking!) or it is unnecessarily convoluted. But on the end of the day, it's doing its job. It can be refined later on, and each error check/test coverage problem/non-idiomatic language feature I forget is a lesson for the next project in the same language/stack. I'm smart? Yeah, think so, at least with this narrow-minded definition. In other aspects, I'm not (like when confronted with these interview-like puzzles: I've always hated them, even as math gimmicks.)

eshvk 13y ago
See this is where it gets into the realm of being subjective. I used to think that getting shit done was the only prime directive that matter. Until, one fine day I found myself given legacy code written in PHP by some dude who hadn't been in the company for years and years. Suppose you had come by my table during that dark and painful period and asked me if I would hire the dude, I would probably have said no, god no. On the flip side, there is a tradeoff. You can't realistically expect to ship if you expect every module to be pretty as fuck. Again, this is also something you realize with more experience? Are you then smarter? This is kind of getting into theory of the mind territory here.
- redblacktree 13y ago
  As with all things, it's a trade-off, and there is a balance somewhere in the middle. i.e. Don't do really dumb things like copy-pasting code everywhere, but also don't feel that every line of code must be a masterpiece. There isn't one rule or paradigm for all situations; you just have to use your best judgment.
- RBerenguel 13y ago
  As redblackthree says below, there's some leeway in there. I guess it comes down to knowing what tradeoffs are you doing to get it done sooner. In my case I usually know where I've done some cheapish job and mark the code area with a "FIX: explanation of what should be done" for when I have time for that. I also eventually come back and clean up whatever code mess I got, or at least comment the mess so it doesn't come biting back at me in the future.

munin 13y ago

> This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason. this has not been my experience, lab / academic jobs are a day of interviews which probably will not have any programming questions because you're hiring a scientist, not a staff programmer, but you will talk about research, ideas, and be expected to think and produce insights on the spot, and you as a candidate will give an hourlong talk. the decision is not made before you show up and the desires of the hiring body are very fickle.