I don't care about getting paid. I don't care if I am doing it at home or in the interviewer's premises.
Don't let me connect to internet. I'll also leave my phone with you just to make sure I don't have access to the internet. I don't mind taking the time away from current employment to go through the process.
BUT PLEASE LEAVE ME ALONE THOUGH WHILE I AM AT IT. FOR GOD'S SAKE DON"T SIT NEXT TO ME AND TALK TO ME OR EXPECT ME TO TALK TO YOU WHILE I AM SOLVING THE PROBLEM !!!
Let's discuss the solution or the non-solution AFTER I have spent some alone time with the problem. I don't mind getting rejected AFTER I have made a serious attempt at it.
It is simply beyond me why people think it's all right for a complete stranger to sit next to a programmer while he is trying to solve a problem under the significant cognitive load of a new environment, new people possibly a laptop/keyboard he has never used.
This did sound like a rant :-/ but what I wanted to say was that the process in the article seems fair enough. Interviewees should be given the alone time to solve the problem.
Most people are decent and sociable enough that once they are one board and are comfortable and familiar with the rest of the team they will be able to function and be reasonable in pair programming envoirnment or other technical discussions as well. BUT not when they are in an interview. No matter how it is sugar coated, interview is where a programmer is getting JUDGED and that by default leads to pressure.
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.
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.
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.
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.
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.
> 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.
Try enlisting services of a consulting company such as ThoughtWorks, Accenture etc. Talk to the people who are already using such consultancies.
Every single job interview I have had this year involved a pair programming session and lists pair-programming as a "culture-fit" requirement.
The very latest one I had to go to, I had already warned the recruiter that that is not my strong point but he still sent me in anyways !
>But they really don't have anything to do with each other
I was trying to propose that maybe enforced pair programming is actually of no real value or very little value it at all and hence pair-programming has nothing to do with anything actually.
I value formal code-reviews. I have ZERO love for being forced into pair-programming be it in a real job or during an interview.
Somehow pair-programming caught on because KoolAid happens.
Pair programming neatly sidesteps a number of problems, when done well. For a team, it helps to spread knowledge among the team, encourages people to follow the team discipline, gives a second pair of eyes on any bugs and gets people up and running faster.
done well is the tricky bit. You need people who get on ok with it, social skills need to be developed, and you need discipline around not committing code which hasn't at least been reviewed. Social skills is the hardest part IME: knowing you can ask for a break, some time to think, or to split for some research before resuming work as a pair.
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.
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.
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.
> 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.
'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.
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.
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."
I have to agree. Not necessarily on SO in particular, but on having access to resources in general.
Maybe someone who's only ever done web stuffs in javascript and RoR and the one framework that is being used for the task at the company he's applying for, it's not necessary to check facts.
When you've done two dozen programming languages, everything including low level assembly hacking, embedded & kernel development, graphics programming, network services, traditional desktop software, mobile software, video games and front end web stuffs and you've used more libraries and frameworks than you can count, it is quite possible that you're more than competent enough as a programmer. Yet you might need a bit of a refresher on whatever tech you're being asked to use because chances are it's not the only thing you focused on last year, or maybe indeed you haven't used it in a year or three.
Of course it's not black and white; if a company needs a C expert right now, somebody who knows all the pitfalls and can point at security issues & UB, then maybe he should do well on a test for that, without a reference. Although even then I'd let him use a copy of the standard (or its draft).
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?
Well, let's explain the downvotes from 1 POV. The "copy/paste" comment just willfully misinterprets how StackOverflow is used.
I think that we just don't believe you. Did you arrive at every job with perfect knowledge in the areas you'd be working on? Have you not had to learn anything on the job?
If that's the case, then you're vastly overqualified. I feel like I'm being utilized as an employee the best when my manager says: "Hey, there's something weird happening in area X" or "I want you to explore feature X" and I get to dive deep into something for a few days. Our strengths are our ability to learn.
I mention it as a copy/paste mechanism as I am surrounded by people who use it for that very purpose.
I also did have the knowledge required for the job I applied for, and whilst I have learned a lot (off my own back) over the last 18+ years, very little of it is actually required, as demonstrated by those others who get given similar tasks that they can complete using Stack Overflow.
I'm definitely in the wrong place, and after a while I sense I lost a lot of perspective due to my peers / surroundings.
Personally, I never use downvotes for things I disagree with, but perhaps some people who are luckier to work in better scenarios believe that situations like mine don't exist - I don't wish anybody to walk in my shoes.
Thank you. I appreciate you taking the time to explain.
That sounds like a crappy job to be in, I'm sorry. I've worked around people who were... negative, and were really bad at explaining things to me, and also kind of hacky. It sucked and it drained my morale.
There are good places out there, _even_ if they're low-skilled environment. I think it's totally a cultural attitude, to be willing to take the time to learn, and to have a good attitude and effort about it. You can copy/paste from SO and still be using it as a learning tool.
I've used dozens of libraries professionally over the past year or so. Some of them I use every day, others I only need to touch once a week or once a month. Why would I be expected to memorise all of this when it takes only a few seconds to look it up?
I use Python, Clojure, ClojureScript, C++11, Javascript and bash regularly. I remember all of the standard library functions and third party libraries that I use a lot. But even after 15 years of using Python, I still have to look up, for example, the datetime module or what functions exist in the collections module. I still need to look up how to use the C++11 chrono library. I still haven't memorised the entire Clojure core functions (there are so many of them!) I still need to look up the DOM API for javascript (but then, I don't use JS that much).
I'm sure part of it is the context switch: if I were using one single language 100% of the time, perhaps I could memorise its core libraries. But why bother when it takes 3 seconds to look up and every professional job I've ever had its perfectly fine (expected even) to look up online documentation on the job.
So why not during an interview too? If your interview isn't testing me on what I'll be doing when I'm on the job for real, then whats the point? Testing my memory isn't a good reflection of my skill when working on real tasks.
Now, when I learned to program, I didn't have internet and worked completely from offline documentation (I learned Visual Basic, C++ and Python this way), so its not that I'm completely incapable of it, but it seems like a terrible use of my resources.
>Then again, I don't really use SO anyway - I know some people use it daily.
Out of curiosity, what do you do professionally? I'm impressed that you have so much domain knowledge memorized that you seldom ever need to look up anything.
StackOverflow often provides an answer to a specific trivial question faster then going through the docs. There is no point to memorize or read plenty of docs for trivial things such as 'sort array of objects by key', etc. I see no problem with this at all.
The OP's point was without internet access you can't find solutions made by others for problems you might not frequently run into in your daily job.
Example: you have a failing install of a package in a linux version you never used before where the solution would be to increase ulimit but you are applying for a frontend position so you don't even know what ulimit is, but by a quick search on google for the error message there is an article providing a 1 liner for this issue.
Basically, you just wrote nearly (exactly?) what I wanted to write. I'm good at algorithm problems. I LIKE algorithm problems, but having someone watching me on a whiteboard in a high pressure situation diminishes my abilities. At a minimum, it is a distraction. If it is an easy or familiar problem then it usually doesn't matter and we can discuss the solution and I might even want to talk about it. But if it is a tricky problem -- and a lot of tech companies intentionally give problems that are tricky or vague or superficially easy -- then I need to use my natural process for systematically and rigorously tackling tricky problems. I'll still probably finish it in a half hour and we can still talk about the solution and discuss improvements but let me work on it alone first.
One thing I've found from technical interviews is that, due to the pressure to speak and communicate and "show my thoughts", I'm more susceptible to falling prey to trick and vague questions that I would otherwise treat more carefully. This is consistent with scientific results on the way people respond the pressure situations[1]. They tend to fall back on what is familiar instead of trying approaches that may be better. Working alone, there is no fear of judgement if I need to try an unusual strategy[2] that may not work or if I need to backtrack. Let me dabble and doodle on my own sheet of paper and iterate rapidly over whatever comes to mind freely.
Furthermore, turning problem solving into a theatrical event unavoidably increases the cognitive load on an interviewee simply due to the fact that you have to make more decisions. You have the technical decisions like data structures and algorithms which are normal and expected, but on top of that, there are all these non-engineering decisions that you have to make because they want you to talk about how you're solving the problem in real time. Should you mention some fancy algorithm or approach that you are considering? You must choose your words carefully since anything you say can be used against you.
I'm not claiming that everyone works better alone or even that I don't like working with others. I just think that the interviewee should have the option of working on the problem alone for up to 30 minutes. As suggested by parent, we can discuss the solution or non-solution after I've become familiar and comfortable with the problem. One of the worst feelings is when I fail to solve a problem during an interview, only to have the solution come easily when I'm able to tackle the problem in a pressure-free environment. Expecting some kind of portal into someone's mind while they solve an unfamiliar and maybe tricky problem strikes me as overindulgent and voyeuristic. It is a flaw in the current technical interview process and the only way to mitigate its effects is to just get more comfortable interviewing.
[2] - For tough problems, tend to use my own idiosyncratic variant of Z-Notation. I have a very high success rate solving algorithm puzzles when I use it but it is easy to forgot to use it under pressure of an interview.
> Furthermore, turning problem solving into a theatrical event
That's a very interesting perspective actually.
If this process prevails then only a certain personality types will be able to work at companies which conduct such interviews.
The danger is that when the biggest and most successful companies (who's founding members didn't go through the same process, on the contrary were most likely solitary coders) conduct such interviews, the smaller and actually very nice places to work tend to copy the same.
I am somewhat in favor of the likes of Google and Facebook who need to filter an ocean full of applicants following this process.
But I have seen smaller companies copying the same process assuming they will find the similar hires as G and Fb. The funniest/hilarious part is when the recruiters start saying "we have a very bar" with so much conviction. Yes, you are a startup, you have a "very high bar" and you need to hire people who will scour the internet and integrate the various bits they find because they need to take the product from A to B YESTERDAY !!!
Although having said that, I think I may be a bit different from what you described. I actually don't mind whiteboarding or coding with pen and paper and I noticed for me it is a lot easier to "talk my thoughts" while whiteboarding. On the contrary, I get seriously annoyed if I have to talk while actually writing code and if it is during a job interview, I just choke.
> Expecting some kind of portal into someone's mind while they solve an unfamiliar and maybe tricky problem strikes me as overindulgent and voyeuristic. It is a flaw in the current technical interview process and the only way to mitigate its effects is to just get more comfortable interviewing.
Yes. We are problem solvers after all. A way shall be found.
Don't let me connect to internet. I'll also leave my phone with you just to make sure I don't have access to the internet. I don't mind taking the time away from current employment to go through the process.
BUT PLEASE LEAVE ME ALONE THOUGH WHILE I AM AT IT. FOR GOD'S SAKE DON"T SIT NEXT TO ME AND TALK TO ME OR EXPECT ME TO TALK TO YOU WHILE I AM SOLVING THE PROBLEM !!!
Let's discuss the solution or the non-solution AFTER I have spent some alone time with the problem. I don't mind getting rejected AFTER I have made a serious attempt at it.
It is simply beyond me why people think it's all right for a complete stranger to sit next to a programmer while he is trying to solve a problem under the significant cognitive load of a new environment, new people possibly a laptop/keyboard he has never used.
This did sound like a rant :-/ but what I wanted to say was that the process in the article seems fair enough. Interviewees should be given the alone time to solve the problem.
Most people are decent and sociable enough that once they are one board and are comfortable and familiar with the rest of the team they will be able to function and be reasonable in pair programming envoirnment or other technical discussions as well. BUT not when they are in an interview. No matter how it is sugar coated, interview is where a programmer is getting JUDGED and that by default leads to pressure.