8 ms·

Sounds like I'm completely the opposite of you! I'm fine with someone sitting next to me - I love pair programming. But cutting off internet access means no St

by blowski 10y ago

Sounds like I'm completely the opposite of you! I'm fine with someone sitting next to me - I love pair programming. But cutting off internet access means no StackOverflow, no online documentation. The test should be very similar to normal working conditions.

stillworks 10y ago
Interesting to note how different people are indeed. I am fine with white board type situations, don't worry about writing code without IDEs etc (in my very first job vi editor was the only thing we had to write code so I still have instinctive memory to be resourceful without an IDE but I love IntelliJ for most things). Happy to discuss/draw out ideas/solutions on whiteboards. But find it very seriously annoying talking or being expected to talk while I am writing code ! I think the internet-access requirement depends on the problem. If I am expected to solve a problem by first-principles on a core CS topic then I guess internet is of no use ? Online Java Docs for e.g. may not serve a purpose here. If the problem requires using many different tools/APIs for the solution then I guess you are right, internet access adds value.
- TeMPOraL 10y ago
  Indeed interesting how different people are. Here, I'm like you. But it carries over to normal job - I work best when left alone. Especially when I have a tough problem to solve, just having people sitting close to me makes me frustrated, and if they're talking, then I won't be able to concentrate at all. It takes a lot of energy for me to be able to work in the presence of other people.
  - stillworks 10y ago
    I understand where you are coming from... I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. The consulting companies or body shops were happy since they could bill 2x the number of heads for the same amount of time. The "buy-side" of Pair Programming were happy because the KoolAid evidently worked. Don't get me wrong, I am all in favor of getting my code eye-balled by anybody because I know I don't write perfect code 100% of the times and always open to critique and learning. Here's a thought experiment. Have two teams A and B. A are pair programmers i.e. |A| = 2*|B|. Now make team A don't do any unit testing, let them purely rely on pairing to ensure quality. Enforce team B to do TDD to the best of their efforts. I would be personally very interested in knowing where the consumer of the code and writers of the code have more confidence on code quality and functional completeness. Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay.
    - TeMPOraL 10y ago
      I'd love to see that experiment, as I'm actually more inclined to believe in (occasional) pair programming (by the virtue of enforcing some focus) than in TDD. > Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay. Yeah. When I was still a high-schooler and later a university student, I used to laugh at cubicles. Oh, the corporate culture, oh, the rat race, etc. Now that I spent some time in this career, I would voluntarily go to cubicle and even take a pay cut. I now understand that cubicles were a good idea of solving the space/cost constraints. Hell, every now and then I think about building my own cubicle out of pizza boxes, but I'm pretty sure the management wouldn't be happy about it. Over-the-ear headphones suffice for eliminating sound for now, but I still can't focus when I have people walking behind my back.
    - blowski 10y ago
      What works for one person doesn't work for everybody. I feel that it does work for me - it keeps me focused on the problem at hand without getting distracted, over-engineering the solution, or yak-shaving.
    - coldnebo 10y ago
      It's also interesting that the pair vs TDD divide is often based on the solution space. Service/backend programmers often extol TDD because it is easy when working in a single language where your only IO is strings (i.e. Undergrad CS) Front-end programmers may use TDD in certain established contexts, but pair may be more important when there are numerous integrations across unsupported toolchains. For example, when was the last time you used TDD with CSS? Oh? Too hard to verify that the CSS for a page makes it so that you can't click a button or print a page? Oh? Market bug isn't your responsibility? Yeah, I see a lot of defensiveness when TDD is impossibly hard, so it's not "all that". But, use it if it makes sense. Know your tools and use the right tool for the job.
    - deleted 10y ago
      [deleted]
    - yesiamyourdad 10y ago
      > I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. Not sure what you mean. In 25 years, my latest job is the only one that pair, and even then it's only a few teams in a very large organization. I don't think your AB test makes much sense. The two practices are orthogonal. Complementary, but orthogonal. If I had to take one over the other, I'd to TDD, or at least strive for excellent test coverage over pairing, but they really don't have anything to do with each other.
- yesiamyourdad 10y ago
  Some of that really depends on the problem and the language. I program Java full time, yet I'd be useless with vi. I lean heavily on the IDE. I've done this a long time and I firmly believe that I should use the best tools available, not just a text editor or a TEXTAREA, even with syntax highlighting. Having suffered through a couple code interviews in Java, I now pick Python when allowed to pick a language. It seems like the language for me that allows me the best chance of coding effectively without an IDE. I just did a phone screen yesterday that was extremely painful. After 45 minutes of fumbling around the thing mercifully ended and I googled for a few solutions. According to what I read on stack overflow, the problem is unsolvable with the constraints given. I expect to get the "no thanks" email from the recruiter soon and I plan on asking him what the proposed solution to the problem was - not out of spite, but because I'm genuinely curious. Maybe I misunderstood the problem statement.
  - rms_returns 10y ago
    Just out of curiosity, between Eclipse and Netbeans which IDE do you prefer for Java and why?
    - rhombocombus 10y ago
      I prefer IntelliJ, with Eclipse a distant second (I know I'm not the comment author, but I spend 40+ hours a week slanging Java)
      - yesiamyourdad 10y ago
        Hey, you can take the words out of my mouth. I like IntelliJ as well.
mobiuscog 10y ago
Why would you need Stack Overflow ? Seriously, is the ability to copy/query from Stack Overflow expected from 'programmers' these days ?!
- coldnebo 10y ago
  That's a bit rough. I think you are missing the other value proposition for SO: in a world of poorly documented interfaces, it gives cogent, vetted examples of what works. And you still need to have expertise to know which solutions are crap vs gold. In the 'old days' you had maybe one or two languages and the language was the thing (not vast libraries like Java or .NET .. oh excuse me, the guys who used to get teased for the size of the CMS VAX reference are barely a man page in comparison to modern libraries) -- and now we have a proliferation of languages. Any web dev these days has to know at least 5, maybe more. Any old-timer has had to learn dozens during their career. So no, I'm not going to use my precious grey-storage to remember an arcane Perl invocation when I can find it easily on SO. Perhaps I don't meet your definition of 'programmer', but I've seen many junior devs get trapped in SO 'solutions' and wonder how I can possibly glance through 30 solutions and categorize them: "crap, crap, doesn't know what they are talking about, cargo cult, ... ah, there it is.. that's what we should try." Benefit of experience?
  - mobiuscog 10y ago
    I just wouldn't expect to be applying for something / trying to do a test task, where I didn't already have the knowledge. Then again, I don't really use SO anyway - I know somepeople use it daily.
    - wst_ 10y ago
      What does it mean "to have knowledge"? How much information qualifies you to be a knowledgeable? Plenty of us have a knowledge. Until, for one of your project you have to use Spring Boot and Hadoop at the same time. You know them well, you work with them already. But then you put both libs into one project and something throws an exception somewhere deep down in the unknown code. This is unexpected and does not come from your code. Good luck with searching for solution by yourself. Not that it's impossible, and you would learn something, sure, but troubleshooting takes a lot of time, you'd have to keep your current tasks aside and probability is quite high that someone had that problem before you. IMHO, what makes you a good software engineer is not an encyclopedic facts in your head but general knowledge about principles, algorithms, patterns, etc. You don't have to remember all methods of all classes of standard library, for details you can check the web or use IDE. But if someone asks you about thread safe objects you have to know what does it mean. What may go wrong if you fail to make it so? Why properties must be immutable? And what the hell immutability is in the first place? All other things you should be able find in the online documentation / language reference. What makes you a good software engineer is the ability to ask a meaningful questions. We have a powerful tools at our hands these days. Why wouldn't we use them for our benefit? You don't have to remember everything. It is there, within a hand's reach. Sometimes I have a feeling that asking Google the right question to solve your problem should be another skill tested during interviews. What makes you a good software engineer is the ability to switch the tools and adapt quickly to new environment. Give him Internet, give him StackOverflow and ask him to solve a problem in new language, new framework. If he got the concept well, if he knows principles, that should be more than enough to jump in. Don't get me wrong here. I not going to underestimate guys with years of experience. I am not saying he will write flawless code. But he will solve the problem - that's a good start, isn't it?
posterboy 10y ago
'normal conditions' vary widely, normalisation to a lowest common denominator allows for easier comparison. The other extreme end is the young students assumption, "you don't need to know everything, just where you can find it", but the ammount of stuff I have to look up repeatedly increases exponentially with, eg, every wiki-page I read and that just takes too long to the point of impossibility.
- blowski 10y ago
  For any software development position, normal working conditions probably includes an internet connection.
  - posterboy 10y ago
    like, directly plugged into the hypothalamus?
flurdy 10y ago
Agree. Pairing up during the onsite follow up interview whilst you describe and extend your sample app is essential part of my recruitment preferences. That is how I expect people to work once they are hired so I expect candidates to be comfortable with it. Many are not, including me 10 years ago. But most are these days. I don't expect them to solve the problem perfectly during that time, or even at all. The important bit is to test how they try to solve it, and how they communicate during it. Using Dash, google, SO, etc if fine, asking for help is fine. Essentially portray how they would work if hired. Many times this has quickly highlighted complete blaggers, or cowboys that should be rejected, or people caught like rabbit in head lights that are not right for us now (but maybe later). Adding a requirement that completely blows most people's initial domain model is good way to see how people respond, even if the requirement is essentially impossible.
- stillworks 10y ago
  > Agree. Pairing up during the onsite follow up interview > whilst you describe and extend your sample app is > essential part of my recruitment preferences. When you say "describe and extend your sample app", where does this sample app come from ? Do you give the candidate a chance to work or go through the sample app on his own for some time before you pair ? If that is the case then yes, I guess that is probably the correct way to do it. However of late what I have experienced in general is that I have to go in, meet up people for the very first time in my life, they give me a problem and a laptop/computer/pairing station and a written description of the problem which I get maybe five minutes to assess and understand and then... have a go at it, while the strange (sometimes grumpy) developer sits next to me. If I go quiet for 5 minutes I get the "what are you thinking ?" question and then I have to talk while I write code at the same time ! Maybe it works for some or most of the people out there. Not for me.
ar15saveslives 10y ago
Pair programming is not the same as writing code on an interview.
- ebrenes 10y ago
  It's completely different in my opinion, the only similarity is that you have two people and one computer. In pair programming you're both working together, complementing each other to tackle a particular problem or issue. In a good pair programming session we'll both work together to surpass an obstacle. In an interview, one person is observing, testing and ultimately judging the other person, while actively ensuring they do not contribute to the solution of the problem so as not to skew results. Only one person is truly working towards the programming goal, and both participants know this.
RandomOpinion 10y ago
>I love pair programming Yes, but do you love pair programming: -with a person you met less than 5 minutes ago? -on a non-standard programming task you've been given less than a minute to think about? -with a person who is focused on assessing you rather than assisting you? -with your future job at stake and potentially your ability to ever interview at that company again at stake as well? I enjoy pair programming too but I still choke on whiteboard programming questions during interviews. And this is after 20 years in the industry.

by blowski 10y ago

stillworks 10y ago

Interesting to note how different people are indeed. I am fine with white board type situations, don't worry about writing code without IDEs etc (in my very first job vi editor was the only thing we had to write code so I still have instinctive memory to be resourceful without an IDE but I love IntelliJ for most things). Happy to discuss/draw out ideas/solutions on whiteboards. But find it very seriously annoying talking or being expected to talk while I am writing code ! I think the internet-access requirement depends on the problem. If I am expected to solve a problem by first-principles on a core CS topic then I guess internet is of no use ? Online Java Docs for e.g. may not serve a purpose here. If the problem requires using many different tools/APIs for the solution then I guess you are right, internet access adds value.

TeMPOraL 10y ago
Indeed interesting how different people are. Here, I'm like you. But it carries over to normal job - I work best when left alone. Especially when I have a tough problem to solve, just having people sitting close to me makes me frustrated, and if they're talking, then I won't be able to concentrate at all. It takes a lot of energy for me to be able to work in the presence of other people.
- stillworks 10y ago
  I understand where you are coming from... I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. The consulting companies or body shops were happy since they could bill 2x the number of heads for the same amount of time. The "buy-side" of Pair Programming were happy because the KoolAid evidently worked. Don't get me wrong, I am all in favor of getting my code eye-balled by anybody because I know I don't write perfect code 100% of the times and always open to critique and learning. Here's a thought experiment. Have two teams A and B. A are pair programmers i.e. |A| = 2*|B|. Now make team A don't do any unit testing, let them purely rely on pairing to ensure quality. Enforce team B to do TDD to the best of their efforts. I would be personally very interested in knowing where the consumer of the code and writers of the code have more confidence on code quality and functional completeness. Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay.
  - TeMPOraL 10y ago
    I'd love to see that experiment, as I'm actually more inclined to believe in (occasional) pair programming (by the virtue of enforcing some focus) than in TDD. > Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay. Yeah. When I was still a high-schooler and later a university student, I used to laugh at cubicles. Oh, the corporate culture, oh, the rat race, etc. Now that I spent some time in this career, I would voluntarily go to cubicle and even take a pay cut. I now understand that cubicles were a good idea of solving the space/cost constraints. Hell, every now and then I think about building my own cubicle out of pizza boxes, but I'm pretty sure the management wouldn't be happy about it. Over-the-ear headphones suffice for eliminating sound for now, but I still can't focus when I have people walking behind my back.
  - blowski 10y ago
    What works for one person doesn't work for everybody. I feel that it does work for me - it keeps me focused on the problem at hand without getting distracted, over-engineering the solution, or yak-shaving.
  - coldnebo 10y ago
    It's also interesting that the pair vs TDD divide is often based on the solution space. Service/backend programmers often extol TDD because it is easy when working in a single language where your only IO is strings (i.e. Undergrad CS) Front-end programmers may use TDD in certain established contexts, but pair may be more important when there are numerous integrations across unsupported toolchains. For example, when was the last time you used TDD with CSS? Oh? Too hard to verify that the CSS for a page makes it so that you can't click a button or print a page? Oh? Market bug isn't your responsibility? Yeah, I see a lot of defensiveness when TDD is impossibly hard, so it's not "all that". But, use it if it makes sense. Know your tools and use the right tool for the job.
  - deleted 10y ago
    [deleted]
  - yesiamyourdad 10y ago
    > I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. Not sure what you mean. In 25 years, my latest job is the only one that pair, and even then it's only a few teams in a very large organization. I don't think your AB test makes much sense. The two practices are orthogonal. Complementary, but orthogonal. If I had to take one over the other, I'd to TDD, or at least strive for excellent test coverage over pairing, but they really don't have anything to do with each other.
yesiamyourdad 10y ago
Some of that really depends on the problem and the language. I program Java full time, yet I'd be useless with vi. I lean heavily on the IDE. I've done this a long time and I firmly believe that I should use the best tools available, not just a text editor or a TEXTAREA, even with syntax highlighting. Having suffered through a couple code interviews in Java, I now pick Python when allowed to pick a language. It seems like the language for me that allows me the best chance of coding effectively without an IDE. I just did a phone screen yesterday that was extremely painful. After 45 minutes of fumbling around the thing mercifully ended and I googled for a few solutions. According to what I read on stack overflow, the problem is unsolvable with the constraints given. I expect to get the "no thanks" email from the recruiter soon and I plan on asking him what the proposed solution to the problem was - not out of spite, but because I'm genuinely curious. Maybe I misunderstood the problem statement.
- rms_returns 10y ago
  Just out of curiosity, between Eclipse and Netbeans which IDE do you prefer for Java and why?
  - rhombocombus 10y ago
    I prefer IntelliJ, with Eclipse a distant second (I know I'm not the comment author, but I spend 40+ hours a week slanging Java)
    - yesiamyourdad 10y ago
      Hey, you can take the words out of my mouth. I like IntelliJ as well.

mobiuscog 10y ago

Why would you need Stack Overflow ? Seriously, is the ability to copy/query from Stack Overflow expected from 'programmers' these days ?!

coldnebo 10y ago
That's a bit rough. I think you are missing the other value proposition for SO: in a world of poorly documented interfaces, it gives cogent, vetted examples of what works. And you still need to have expertise to know which solutions are crap vs gold. In the 'old days' you had maybe one or two languages and the language was the thing (not vast libraries like Java or .NET .. oh excuse me, the guys who used to get teased for the size of the CMS VAX reference are barely a man page in comparison to modern libraries) -- and now we have a proliferation of languages. Any web dev these days has to know at least 5, maybe more. Any old-timer has had to learn dozens during their career. So no, I'm not going to use my precious grey-storage to remember an arcane Perl invocation when I can find it easily on SO. Perhaps I don't meet your definition of 'programmer', but I've seen many junior devs get trapped in SO 'solutions' and wonder how I can possibly glance through 30 solutions and categorize them: "crap, crap, doesn't know what they are talking about, cargo cult, ... ah, there it is.. that's what we should try." Benefit of experience?
- mobiuscog 10y ago
  I just wouldn't expect to be applying for something / trying to do a test task, where I didn't already have the knowledge. Then again, I don't really use SO anyway - I know somepeople use it daily.
  - wst_ 10y ago
    What does it mean "to have knowledge"? How much information qualifies you to be a knowledgeable? Plenty of us have a knowledge. Until, for one of your project you have to use Spring Boot and Hadoop at the same time. You know them well, you work with them already. But then you put both libs into one project and something throws an exception somewhere deep down in the unknown code. This is unexpected and does not come from your code. Good luck with searching for solution by yourself. Not that it's impossible, and you would learn something, sure, but troubleshooting takes a lot of time, you'd have to keep your current tasks aside and probability is quite high that someone had that problem before you. IMHO, what makes you a good software engineer is not an encyclopedic facts in your head but general knowledge about principles, algorithms, patterns, etc. You don't have to remember all methods of all classes of standard library, for details you can check the web or use IDE. But if someone asks you about thread safe objects you have to know what does it mean. What may go wrong if you fail to make it so? Why properties must be immutable? And what the hell immutability is in the first place? All other things you should be able find in the online documentation / language reference. What makes you a good software engineer is the ability to ask a meaningful questions. We have a powerful tools at our hands these days. Why wouldn't we use them for our benefit? You don't have to remember everything. It is there, within a hand's reach. Sometimes I have a feeling that asking Google the right question to solve your problem should be another skill tested during interviews. What makes you a good software engineer is the ability to switch the tools and adapt quickly to new environment. Give him Internet, give him StackOverflow and ask him to solve a problem in new language, new framework. If he got the concept well, if he knows principles, that should be more than enough to jump in. Don't get me wrong here. I not going to underestimate guys with years of experience. I am not saying he will write flawless code. But he will solve the problem - that's a good start, isn't it?

posterboy 10y ago

'normal conditions' vary widely, normalisation to a lowest common denominator allows for easier comparison. The other extreme end is the young students assumption, "you don't need to know everything, just where you can find it", but the ammount of stuff I have to look up repeatedly increases exponentially with, eg, every wiki-page I read and that just takes too long to the point of impossibility.

blowski 10y ago
For any software development position, normal working conditions probably includes an internet connection.
- posterboy 10y ago
  like, directly plugged into the hypothalamus?

flurdy 10y ago

Agree. Pairing up during the onsite follow up interview whilst you describe and extend your sample app is essential part of my recruitment preferences. That is how I expect people to work once they are hired so I expect candidates to be comfortable with it. Many are not, including me 10 years ago. But most are these days. I don't expect them to solve the problem perfectly during that time, or even at all. The important bit is to test how they try to solve it, and how they communicate during it. Using Dash, google, SO, etc if fine, asking for help is fine. Essentially portray how they would work if hired. Many times this has quickly highlighted complete blaggers, or cowboys that should be rejected, or people caught like rabbit in head lights that are not right for us now (but maybe later). Adding a requirement that completely blows most people's initial domain model is good way to see how people respond, even if the requirement is essentially impossible.

stillworks 10y ago
> Agree. Pairing up during the onsite follow up interview > whilst you describe and extend your sample app is > essential part of my recruitment preferences. When you say "describe and extend your sample app", where does this sample app come from ? Do you give the candidate a chance to work or go through the sample app on his own for some time before you pair ? If that is the case then yes, I guess that is probably the correct way to do it. However of late what I have experienced in general is that I have to go in, meet up people for the very first time in my life, they give me a problem and a laptop/computer/pairing station and a written description of the problem which I get maybe five minutes to assess and understand and then... have a go at it, while the strange (sometimes grumpy) developer sits next to me. If I go quiet for 5 minutes I get the "what are you thinking ?" question and then I have to talk while I write code at the same time ! Maybe it works for some or most of the people out there. Not for me.

ar15saveslives 10y ago

Pair programming is not the same as writing code on an interview.

ebrenes 10y ago
It's completely different in my opinion, the only similarity is that you have two people and one computer. In pair programming you're both working together, complementing each other to tackle a particular problem or issue. In a good pair programming session we'll both work together to surpass an obstacle. In an interview, one person is observing, testing and ultimately judging the other person, while actively ensuring they do not contribute to the solution of the problem so as not to skew results. Only one person is truly working towards the programming goal, and both participants know this.

RandomOpinion 10y ago

>I love pair programming Yes, but do you love pair programming: -with a person you met less than 5 minutes ago? -on a non-standard programming task you've been given less than a minute to think about? -with a person who is focused on assessing you rather than assisting you? -with your future job at stake and potentially your ability to ever interview at that company again at stake as well? I enjoy pair programming too but I still choke on whiteboard programming questions during interviews. And this is after 20 years in the industry.