15 ms·

I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate thi

I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had never seen a mainframe. I was told about 20 years ago to write a program in perl, my boss gave me a perl book with the assignment because I didn't know perl and I did it. This is not a bad way to go about work. Every codebase is new. Every job has a steep learning curve. Every requirement is a conversation which may only be internal, but has to always happen. Every programmer you work with is someone whose preferences, strengths, styles, and weaknesses you need to have intuition on. People good at those things are what make good programmers. That's why general competency, ability to learn, not to create a mess and not to waste time on stupid things are the only things I care about. That's really it. Preexisting technical skills aren't as important as how dynamically you can apply new ones.

quickthrower2 8y ago
Sadly I’m yet to meet an employer who thinks like this. Especially in Australia. I’m a C# developer not because I was born with C# DNA but because to use any other language in suddenly looking at junior wages. Even though I could do a great job in any programmming language. It’s insane.
- wryun 8y ago
  I've worked at 4 software companies in Australia so far and none have been concerned about which programming languages I know (admittedly not for super high wages, but still...)
  - quickthrower2 8y ago
    So how did they do the code test? Did they say you can do it in any language? I interviewed for atlassian a few years ago. They gave me a tricky Java test, the kind that you’d only pass if you’ve been battling Java for years and know the gotchas. So that was a fail. I could have studied Java harder, but I’ve only got so much time and so many opportunities.
    - wryun 8y ago
      1 don't remember, 1 any (but need SQL), 1 Java (Atlassian, actually, but only the easy screen - may have been the particular division here), 1 no test because they knew me.
- dzonga 8y ago
  out of curiosity how high / low relatively are the aussie wages compared to us ones ?
  - quickthrower2 8y ago
    They are lower, but better than continental Europe. I here that SF people are getting $130k out of uni. That would be a rare high salary here (180k Aud). Probably a manager of 100 people or a good cider working in trading, or a smart employer who doesn’t want to play the market rates game. Salary is total comp here pretty much.
meijer 8y ago
> Do you see what's not there? Programming language competency. Database knowledge. Things like that. I hear this a lot, but I'm not sure I agree 100%. I want to work with people who can write idiomatic code and are able to use a database efficiently (or who are at least willing to learn these things).
- indigochill 8y ago
  I prefer working with idiomatic code. On the other hand, we hired a guy who didn't write idiomatic code but who was a brilliant engineer in general and he was overall a great hire even if I had to bring him up to speed on a couple style points. Overall, I found his general engineering chops dramatically outweighed the minor annoyance of tidying up style foibles.
- lucideer 8y ago
  Some small counterpoints on idiomatic code: 1. I've worked with people with years of experience in a language who can't (well, really, "won't") write idiomatic code in that language. This has—in my experience—typically come down to overconfidence/arrogance built on top of their experience whereby they've spent enough time with the language to develop their own "better" style. 2. Learning quickly on-the-job typically involved picking up idiomatic style first, before you really gain a deep understanding of the underlying workings. Ideally a good engineer should gain both, but at least initially, I haven't found the former to be a problem for "good" engineers starting out on something new. 3. For some language ecosystems, what's idiomatic changes over time. Flexibility and adaptibility is key to being a good engineer, but if someone has a lot of experience but isn't so adaptible (and/or hasn't brushed up on modern techniques in their ecosystem), this can also lead to non-idiomatic style. I get that some of the things above should be red flags "in an of themselves" when hiring, but I'm just pointing out that a focus on past familiarity with tech can cloud things somewhat, and shouldn't be implicitly prioritised.
- augustk 8y ago
  Sometimes idiomatic code results in code which is hard to understand, as exemplified by the C idiom `while (s++ = t++);' for copying a string from t to s. It's always good to be able to read idiomatic code, however.
jankotek 8y ago
> ability to learn, not to create a mess and not to waste time on stupid things People do stupid things and create a mess, while they learn.
- sidlls 8y ago
  They are learning at a new job anyway: the code base, tech stack, and social constructs that contributed to these. Learning the syntax and idioms of a new language is the smallest thing in most cases. Unless the language is particularly esoteric I submit that worrying about the "mess" made by learning it is hardly worth considering compared to those other things.
C1sc0cat 8y ago
That's what happened at my first job - told to get the book on Fortran from company library and learn it.
- DoofusOfDeath 8y ago
  To be fair, I found Fortran 77 to have the easiest learning curve of any language I've had to pick up. It only required about 2-3 hours of reading, plus a little more Googling to understand the challenges of having it interact with C++ code.
externalreality 8y ago
I wish everyone thought that way but they don't. In today's rapid paced world if you don't know Rails (not even Ruby) but Rails, for example, and we're using it - then you ain't in... and here write this 8 hour code test so we can subjectively judge it because grading code tests to see if you don't put logic in your controllers make our egos hum.
- jimbokun 8y ago
  Maybe nitpicking certain micro-design choices isn't always helpful, and maybe it doesn't need to be a task requiring 8 hours, but I believe a "work sample" of actual code is the only technique that has any research backing it as a good way to evaluate potential hires.
  - yitianjian 8y ago
    If you're recruiting with a specific company and specific team that you love, sure. But I can't imagine committing multiple hours of my time to each random company's take-homes. As a rule I don't really do any take-homes - the couple I've done haven't been very useful in terms of my own time investment into the problems themselves, and the companies have not been worth it to go above and beyond.
    - pmiller2 8y ago
      This is my exact issue with take-home tasks: I can get to an onsite or a rejection with most other companies after a 15 minute recruiter call and a 45-60 minute technical phone screen. So, why do I want to do a 2+ hour homework assignment? Most of the time, there simply is no compelling reason to do so.
      - llamataboot 8y ago
        I greatly prefer take-homes, because I feel they show off the quality of what I can do under actual coding conditions (rather than the stress of live coding or the BS of whiteboard coding) but it does get a bit tiresome. Especially because it is rarely a 2 hour assignment, they can be 8-16 easy. Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps. I'm sorry, but a full week's of unpaid work that I have to fit around my actual day job is just not practical, I know you want to make a good decision, but really...???? The best I've seen recently is a company that paid an hourly wage for 2 days worth of take-homes. Not consulting wages, but a good wage. It gives them incentives not to invite everyone in the world to do their test, and gives the interviewee something for their time.
kpollich 8y ago
Couldn't agree more. An ability to learn quickly, to self-teach, to solve problems is vastly more important than any degree of exposure to a specific piece of technology. These characteristics are as much about your skill level as they are about your attitude and approach to software engineering, as well.
TallGuyShort 8y ago
I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job, but then I take it really far beyond what I actually expect them to know, to the point where a lot of the details are unknown, and the details matter a lot in determining what kinds of solutions will be successful. Do they start BS'ing me? Do they confidently walk into really nasty parts of the problem without recognizing the pitfalls? Or do they tell me they're a little stuck? Do they ask which trade-offs to make? Do they ask if they can do some Googling for prior research on the problem? Do they explain what they would try and what pitfalls they would watch our for, or how they would validate their idea? Do they ask if they can make some simplifying assumptions for practical purposes? There's a lot of right and wrong answers but really I want to see their attitude and communication. My first couple of hires before I did this were a brilliant computer scientist and a guy with a business degree and some coding background. I was surprised to see the guy with the business degree excel because we weren't doing many CS-hard problems, and an ability to manage time, talk about the problem, and navigate the project life cycle were far more important than classic algorithm knowledge. He needed to know how to code and debug, for sure, but like most software jobs, his soft skills were a force multiplier. I'm pretty sure this has been done with me - I was given a problem and told to come up with something like an O(n log n) solution, and I honestly couldn't do it. I tried a few different approaches but I could think of really bad pathological cases for all of them. The interviewer gave me a few suggestions which I explored and I kept exploring them and then admitted I didn't see a way forward. I thought I was bombing and then he told me I did really well. I looked up the problem and found out he had done Ph.D. research in that area, and there was no general O(n log n) solution - only solutions that could do that in most practical cases.
- moosey 8y ago
  I would think that anyone hiring a Ph.D. in Computer Science would be looking for a different kind of output than the knowledge of actually doing software development and the associated project management/time management work. I would imagine that such people, if placed optimally, would be doing largely self-directed work with an expectation of solving a very complicated problem, with work output that looked more like a thesis than a program. I further surmise that very few companies need these kinds of people. If your needs are people that can be managed to do basic programming tasks (my job as well), then that's what you hire. That's something like 99% of all programming work. It's like hiring someone that understands the building of nuclear power plants, and being surprised that they don't understand basic home building codes. The saddest part of it, for me, though, is that someone with a Ph.D. in Computer Science that is searching for a job in the non-research sector is probably having a really bad time. Research is happening, but I don't think it will jump in a very large way until there are a lot more dollars being pumped into research using public money.
mp01 8y ago
How do you check for those things in an interview? I'm not suggesting you can't, I'm genuinely asking.
- kristopolous 8y ago
  You talk with them. You've probably worked with enough people that you can sniff out the fakes
Egraveline 8y ago
In your opinion are there any common signs you see that indicate someone is good at dynamically applying new skills? or even better is there any signs that clearly idcated they aren;t good? you talked about paying attention to their attitude but I mean more specific things like, if they said they use Emacs and write bash scripts would you take that as arrogance or that they are competent?
thoman23 8y ago
It sounds a bit like you are primarily selecting for high IQ, with a side of good attitude. I tend to agree with that.
systemspeed 8y ago
My experience has been that interviewers like you are rare. I may have reflected on my observations incorrectly, but it seems to me that depending on a newcomer to quickly learn a language and adapt is seen as a high-risk investment. I consider myself an adaptable person, and while I was able to make this impression upon prospective employers in my early days, they would always weigh this against the cost of training me for "longer" than the average employee. In a sense, they were right. I have noticed myself increasingly comfortable with new codebases whenever I change jobs, so experience definitely counts for something.
- hinkley 8y ago
  Yeah, too often I've had interviewers who were far too eager to go and go all the way down to the minor corner cases of a problem (even if I try to beg off of them) and in the end I have no time to ask interesting questions. Questions that might reveal more about my skills than the last two corner cases.

quickthrower2 8y ago

Sadly I’m yet to meet an employer who thinks like this. Especially in Australia. I’m a C# developer not because I was born with C# DNA but because to use any other language in suddenly looking at junior wages. Even though I could do a great job in any programmming language. It’s insane.

wryun 8y ago
I've worked at 4 software companies in Australia so far and none have been concerned about which programming languages I know (admittedly not for super high wages, but still...)
- quickthrower2 8y ago
  So how did they do the code test? Did they say you can do it in any language? I interviewed for atlassian a few years ago. They gave me a tricky Java test, the kind that you’d only pass if you’ve been battling Java for years and know the gotchas. So that was a fail. I could have studied Java harder, but I’ve only got so much time and so many opportunities.
  - wryun 8y ago
    1 don't remember, 1 any (but need SQL), 1 Java (Atlassian, actually, but only the easy screen - may have been the particular division here), 1 no test because they knew me.
dzonga 8y ago
out of curiosity how high / low relatively are the aussie wages compared to us ones ?
- quickthrower2 8y ago
  They are lower, but better than continental Europe. I here that SF people are getting $130k out of uni. That would be a rare high salary here (180k Aud). Probably a manager of 100 people or a good cider working in trading, or a smart employer who doesn’t want to play the market rates game. Salary is total comp here pretty much.

meijer 8y ago

> Do you see what's not there? Programming language competency. Database knowledge. Things like that. I hear this a lot, but I'm not sure I agree 100%. I want to work with people who can write idiomatic code and are able to use a database efficiently (or who are at least willing to learn these things).

indigochill 8y ago
I prefer working with idiomatic code. On the other hand, we hired a guy who didn't write idiomatic code but who was a brilliant engineer in general and he was overall a great hire even if I had to bring him up to speed on a couple style points. Overall, I found his general engineering chops dramatically outweighed the minor annoyance of tidying up style foibles.
lucideer 8y ago
Some small counterpoints on idiomatic code: 1. I've worked with people with years of experience in a language who can't (well, really, "won't") write idiomatic code in that language. This has—in my experience—typically come down to overconfidence/arrogance built on top of their experience whereby they've spent enough time with the language to develop their own "better" style. 2. Learning quickly on-the-job typically involved picking up idiomatic style first, before you really gain a deep understanding of the underlying workings. Ideally a good engineer should gain both, but at least initially, I haven't found the former to be a problem for "good" engineers starting out on something new. 3. For some language ecosystems, what's idiomatic changes over time. Flexibility and adaptibility is key to being a good engineer, but if someone has a lot of experience but isn't so adaptible (and/or hasn't brushed up on modern techniques in their ecosystem), this can also lead to non-idiomatic style. I get that some of the things above should be red flags "in an of themselves" when hiring, but I'm just pointing out that a focus on past familiarity with tech can cloud things somewhat, and shouldn't be implicitly prioritised.
augustk 8y ago
Sometimes idiomatic code results in code which is hard to understand, as exemplified by the C idiom `while (s++ = t++);' for copying a string from t to s. It's always good to be able to read idiomatic code, however.

jankotek 8y ago

> ability to learn, not to create a mess and not to waste time on stupid things People do stupid things and create a mess, while they learn.

sidlls 8y ago
They are learning at a new job anyway: the code base, tech stack, and social constructs that contributed to these. Learning the syntax and idioms of a new language is the smallest thing in most cases. Unless the language is particularly esoteric I submit that worrying about the "mess" made by learning it is hardly worth considering compared to those other things.

C1sc0cat 8y ago

That's what happened at my first job - told to get the book on Fortran from company library and learn it.

DoofusOfDeath 8y ago
To be fair, I found Fortran 77 to have the easiest learning curve of any language I've had to pick up. It only required about 2-3 hours of reading, plus a little more Googling to understand the challenges of having it interact with C++ code.

externalreality 8y ago

I wish everyone thought that way but they don't. In today's rapid paced world if you don't know Rails (not even Ruby) but Rails, for example, and we're using it - then you ain't in... and here write this 8 hour code test so we can subjectively judge it because grading code tests to see if you don't put logic in your controllers make our egos hum.

jimbokun 8y ago
Maybe nitpicking certain micro-design choices isn't always helpful, and maybe it doesn't need to be a task requiring 8 hours, but I believe a "work sample" of actual code is the only technique that has any research backing it as a good way to evaluate potential hires.
- yitianjian 8y ago
  If you're recruiting with a specific company and specific team that you love, sure. But I can't imagine committing multiple hours of my time to each random company's take-homes. As a rule I don't really do any take-homes - the couple I've done haven't been very useful in terms of my own time investment into the problems themselves, and the companies have not been worth it to go above and beyond.
  - pmiller2 8y ago
    This is my exact issue with take-home tasks: I can get to an onsite or a rejection with most other companies after a 15 minute recruiter call and a 45-60 minute technical phone screen. So, why do I want to do a 2+ hour homework assignment? Most of the time, there simply is no compelling reason to do so.
    - llamataboot 8y ago
      I greatly prefer take-homes, because I feel they show off the quality of what I can do under actual coding conditions (rather than the stress of live coding or the BS of whiteboard coding) but it does get a bit tiresome. Especially because it is rarely a 2 hour assignment, they can be 8-16 easy. Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps. I'm sorry, but a full week's of unpaid work that I have to fit around my actual day job is just not practical, I know you want to make a good decision, but really...???? The best I've seen recently is a company that paid an hourly wage for 2 days worth of take-homes. Not consulting wages, but a good wage. It gives them incentives not to invite everyone in the world to do their test, and gives the interviewee something for their time.

kpollich 8y ago

Couldn't agree more. An ability to learn quickly, to self-teach, to solve problems is vastly more important than any degree of exposure to a specific piece of technology. These characteristics are as much about your skill level as they are about your attitude and approach to software engineering, as well.

TallGuyShort 8y ago

I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job, but then I take it really far beyond what I actually expect them to know, to the point where a lot of the details are unknown, and the details matter a lot in determining what kinds of solutions will be successful. Do they start BS'ing me? Do they confidently walk into really nasty parts of the problem without recognizing the pitfalls? Or do they tell me they're a little stuck? Do they ask which trade-offs to make? Do they ask if they can do some Googling for prior research on the problem? Do they explain what they would try and what pitfalls they would watch our for, or how they would validate their idea? Do they ask if they can make some simplifying assumptions for practical purposes? There's a lot of right and wrong answers but really I want to see their attitude and communication. My first couple of hires before I did this were a brilliant computer scientist and a guy with a business degree and some coding background. I was surprised to see the guy with the business degree excel because we weren't doing many CS-hard problems, and an ability to manage time, talk about the problem, and navigate the project life cycle were far more important than classic algorithm knowledge. He needed to know how to code and debug, for sure, but like most software jobs, his soft skills were a force multiplier. I'm pretty sure this has been done with me - I was given a problem and told to come up with something like an O(n log n) solution, and I honestly couldn't do it. I tried a few different approaches but I could think of really bad pathological cases for all of them. The interviewer gave me a few suggestions which I explored and I kept exploring them and then admitted I didn't see a way forward. I thought I was bombing and then he told me I did really well. I looked up the problem and found out he had done Ph.D. research in that area, and there was no general O(n log n) solution - only solutions that could do that in most practical cases.

moosey 8y ago
I would think that anyone hiring a Ph.D. in Computer Science would be looking for a different kind of output than the knowledge of actually doing software development and the associated project management/time management work. I would imagine that such people, if placed optimally, would be doing largely self-directed work with an expectation of solving a very complicated problem, with work output that looked more like a thesis than a program. I further surmise that very few companies need these kinds of people. If your needs are people that can be managed to do basic programming tasks (my job as well), then that's what you hire. That's something like 99% of all programming work. It's like hiring someone that understands the building of nuclear power plants, and being surprised that they don't understand basic home building codes. The saddest part of it, for me, though, is that someone with a Ph.D. in Computer Science that is searching for a job in the non-research sector is probably having a really bad time. Research is happening, but I don't think it will jump in a very large way until there are a lot more dollars being pumped into research using public money.

mp01 8y ago

How do you check for those things in an interview? I'm not suggesting you can't, I'm genuinely asking.

kristopolous 8y ago
You talk with them. You've probably worked with enough people that you can sniff out the fakes

Egraveline 8y ago

In your opinion are there any common signs you see that indicate someone is good at dynamically applying new skills? or even better is there any signs that clearly idcated they aren;t good? you talked about paying attention to their attitude but I mean more specific things like, if they said they use Emacs and write bash scripts would you take that as arrogance or that they are competent?

thoman23 8y ago

It sounds a bit like you are primarily selecting for high IQ, with a side of good attitude. I tend to agree with that.

systemspeed 8y ago

My experience has been that interviewers like you are rare. I may have reflected on my observations incorrectly, but it seems to me that depending on a newcomer to quickly learn a language and adapt is seen as a high-risk investment. I consider myself an adaptable person, and while I was able to make this impression upon prospective employers in my early days, they would always weigh this against the cost of training me for "longer" than the average employee. In a sense, they were right. I have noticed myself increasingly comfortable with new codebases whenever I change jobs, so experience definitely counts for something.

hinkley 8y ago
Yeah, too often I've had interviewers who were far too eager to go and go all the way down to the minor corner cases of a problem (even if I try to beg off of them) and in the end I have no time to ask interesting questions. Questions that might reveal more about my skills than the last two corner cases.