3 ms·

I think an under-tested aspect of software engineering is the ability to research solutions on the internet. Just give people a search bar and ask them to solv

I think an under-tested aspect of software engineering is the ability to research solutions on the internet. Just give people a search bar and ask them to solve a problem outside their comfort zone. See what terms they use and how quickly they can arrive at a useful link. No pseudo-code or architectural diagrams needed. Just a link with a plausible solution. Because that's how most learning on the job actually happens.

jpindar 8y ago
If I were interviewing that would absolutely be an important part of the interview. It never ceases to amaze me how bad some people are at searching.
- scottyelich 8y ago
  Hell, I've coded in languages that I didn't even know (didn't really even know what the language was -- I think it was like VB or something) by copying terms from some sample, reference or other part of the code and putting in the term or idea I was looking for. Additionally, just try to look up items on a language that is in (constant?) flux like Swift. Swift 1.x? 2.x? 3.x? 4.x? What's the API today -- naming convention changed, parameters changed, etc. All I can say is that thank goodness Google allows for date ranges with searches. :-)
tluyben2 8y ago
I agree. I interviewed people who optimized for white boarding interviewed and, as such, could knock up CS algorithms which you can trivially import from libraries all I wanted. But when asking them a problem they did not encounter before and Google, they got very stuck. While, every time, there was a way of writing the query to Google that had the answer in the top 3 (usually #1). People waste crazy time on reinventing the wheel. Anecdotal: we had some problem to solve which required qua a lot of code to solve and only old sites with broken links came up in Google for the guy solving it so he decided to implement it himself. When I asked why that task was taking so long he showed me what he was implementing. The code he was writing had an implementation on an old site which had a broken link to the code; when I copied the name of the zip file that was linked in github; there was the code. It had no description or comments; someone just checked it in. It was not perfect code, but it shaved off a few days of writing it from scratch anyway. I care about being able to code, which can be assessed from past code and a pair programming session and then efficient problem solving using your brain and internet. The latter is somehow less common. So my favorite way now is; I ask them to 'solve' a problem they have never encountered and that cannot physically be done during the interview time (I am interviewing for software development and in our field you get asked for things that cannot be done in the time you are asked to do it all the time, so I need to see how you handle that); give them time to Google possible ways to do it and present a little plan. Then they need to pick, out of the plan, something they think they can do inside the interview time (see how confident they are and if they have any sense about low hanging fruit or estimations; I might suggest something else if the task they pick is only installing libraries for an hour ;) and we'll sit together behind a monitor and do it together. I'll usually tell them to stop after 15-30 minutes as I have seen enough at that time.
scottyelich 8y ago
I did an interview problem like this a while back (was about combining CIDR blocks) and I found an answer on the Internet. I coded up a similar solution (I used a slightly different data structure with a slight optimization just to show I didn't copy the algorithm exactly). The place actually complemented me on my Google foo as they claimed they asked the question because they knew (thought?) people couldn't look up the answer. Of course, they dinged me by saying my code had too many comments (nevermind I was detailing WHY and HOW my algorithm was different from the Google results). I didn't get any love for the man(1) page I made either. Oh well, can't please everyone. :-)

jpindar 8y ago

If I were interviewing that would absolutely be an important part of the interview. It never ceases to amaze me how bad some people are at searching.

scottyelich 8y ago
Hell, I've coded in languages that I didn't even know (didn't really even know what the language was -- I think it was like VB or something) by copying terms from some sample, reference or other part of the code and putting in the term or idea I was looking for. Additionally, just try to look up items on a language that is in (constant?) flux like Swift. Swift 1.x? 2.x? 3.x? 4.x? What's the API today -- naming convention changed, parameters changed, etc. All I can say is that thank goodness Google allows for date ranges with searches. :-)

tluyben2 8y ago

I agree. I interviewed people who optimized for white boarding interviewed and, as such, could knock up CS algorithms which you can trivially import from libraries all I wanted. But when asking them a problem they did not encounter before and Google, they got very stuck. While, every time, there was a way of writing the query to Google that had the answer in the top 3 (usually #1). People waste crazy time on reinventing the wheel. Anecdotal: we had some problem to solve which required qua a lot of code to solve and only old sites with broken links came up in Google for the guy solving it so he decided to implement it himself. When I asked why that task was taking so long he showed me what he was implementing. The code he was writing had an implementation on an old site which had a broken link to the code; when I copied the name of the zip file that was linked in github; there was the code. It had no description or comments; someone just checked it in. It was not perfect code, but it shaved off a few days of writing it from scratch anyway. I care about being able to code, which can be assessed from past code and a pair programming session and then efficient problem solving using your brain and internet. The latter is somehow less common. So my favorite way now is; I ask them to 'solve' a problem they have never encountered and that cannot physically be done during the interview time (I am interviewing for software development and in our field you get asked for things that cannot be done in the time you are asked to do it all the time, so I need to see how you handle that); give them time to Google possible ways to do it and present a little plan. Then they need to pick, out of the plan, something they think they can do inside the interview time (see how confident they are and if they have any sense about low hanging fruit or estimations; I might suggest something else if the task they pick is only installing libraries for an hour ;) and we'll sit together behind a monitor and do it together. I'll usually tell them to stop after 15-30 minutes as I have seen enough at that time.

scottyelich 8y ago

I did an interview problem like this a while back (was about combining CIDR blocks) and I found an answer on the Internet. I coded up a similar solution (I used a slightly different data structure with a slight optimization just to show I didn't copy the algorithm exactly). The place actually complemented me on my Google foo as they claimed they asked the question because they knew (thought?) people couldn't look up the answer. Of course, they dinged me by saying my code had too many comments (nevermind I was detailing WHY and HOW my algorithm was different from the Google results). I didn't get any love for the man(1) page I made either. Oh well, can't please everyone. :-)