I recently wrote a book on how we as professionals need to stop whining and start focusing on developing our skills.
One data point that I obtained for the book (but didn't quite include in the book because it was too programmer centric) was based on 22 job interviews for programming positions I conducted for one of my clients over a period of two months.
Though this is hardly a considerable sample size, it did reveal some interesting facts about programmers. There were two seemingly disconnected questions that we asked at completely different moments of time during the interview:
- Talk about a few things in your current organization or manager that you don't like / aren't happy with.
- Solve a simple programming problem (one that was much easier than the famous Fizz Buzz problem).
The goal was to study the correlation between whining and coding abilities. Here's a subset of the data we collected (of course I wasn't carrying stop watches in the interviews so the minutes have been rounded up to an interval of 1):
Even though there are some exceptions in the above data set if you look at the graph what's evident is that there seems to be a strong co-relation between whining and being able to solve ridiculously simple programming problems.
That was interesting. But what was even more interesting was the actual program the candidates were being asked to solve. If Jeff Atwood wonders why programmers can't program, when they can't solve Fizz Buzz; here's a problem that is much more easier than Fizz Buzz and yet:
- About 14% just couldn't solve the problem in less then 10 minutes - which is when we moved on to the next question.
- About 40% took more than 5 minutes to solve the problem and / or had to be corrected more than once.
- Only about 14% could solve this problem in 2 minutes or less.
- About 82% had to be corrected at-least once before they solved the problem. (which means they actually got it wrong the first time around!)
And the problem they were solving?
Print 100 to 1.
That's it.
That was the question.
The Catch?
You need to start with "for(int i=0;" and continue from there - you cannot write anything before "for(int i=0;" and you can't use two loops.
[Update: This is supposed to be a code snippet which already exists inside a function, so you can safely assume that inclusion of headers and declaration of the functions etc. is already done for you and you don't need to worry about that.]
Go ahead. Try it out. The answer really won't take you more than 2 minutes and should not take more than 4 lines of code including the curly braces but you can write as many lines as you want.
If you get the right output without mistakes in a reasonable amount of time we consider the answer correct.
Go on. Try it. And once you've solved it - go on and make it a part of your interview process and see countless programmers fumble, take really long pauses, struggle and even give up on the question.
Personally, I came across two programmers who said they could not do it because the question was too complicated after over 10 minutes of struggling with the problem.
While this little experiment establishes correlation between whining and skills it doesn't establish any causation. In other words the data doesn't really tell us if programmers whine because they just don't have the skillsets to do their job, or programmers don't have the skillsets to do their job because they whine.
Maybe our programmers are not skilled because they whine a lot or maybe they whine a lot because we've lowered our bars of what we expect from our programmers and don't demand or challenge them enough to even practice the most basic programming skills.
Either ways the sad reality of where the IT industry stands today is that you don't even need Fizz Buzz to differentiate a bad non-programmer from a good one - Just asking them to print 100 to 1 is usually good enough.
[Update: A lot of folks seemed to get an idea that this is a black and white question and that you can make a hiring decision based on this. It's not. But it does give you an important data point to evaluate someone. For example, if someone clears this question and then fumbles at other basics it might be a reason to not hire him / her. At the same time if someone doesn't answer this and go on to answers other complex algorithmic questions really well, you may decide to hire him / her. Putting the candidate at ease is also important here. The candidates should not be asked or pushed to solve the question in less than 2 minutes. The goal here isn't to stress out the candidates. The goal is to watch them think about and solve a simple problem. Merely present the problem to them and watch their approach and time taken. Couple that up with their tendency to whine and the question provides some very useful insights about a person's approach towards solving problems and their ability to ship.]
[Update: Thanks to the folks who were rightly annoyed by the confusing visualization / chart done in the original post and pointed out how confusing that data visualization was. Special thanks to Jacob for creating the scatterplot using the same dataset. Post updated with the scatterplot.]
Opened your blog after a long time...don't know you will be happy or angry!!! ,good to see that you are back and kicking.Please keep on posting and help us leech..but
on a serious note I think this problem is a tad bit simple and you are exaggerating a little, though I belong to the bracket who had to be rectified around 5 times or
so for the famous Fizz Buzz problem in the Avaya Room :).Anyways its great that u r back, Keep on seeding..!!
Regards
TARAFDAR (eFORCE)
manager and asked a programming question. And you are complaining the programmers are whining. Doesn't make any sense to me.
@Subhojit - Hey! Happy to hear back from you! Think the problem is simple? If you happen to take interviews just ask the question – “with” the catch (which is you need to begin with “for(int=0”) and see programmers fumble and take unusually long volumes of time in solving this. Let me know how that goes.
@Brian, Thanks Brian. Do let us know the outcomes when you add it to your interview questions.
@VR – The graph basically shows clear correlation with amount of time taken in whining and amount of time taken in solving the problem – when one goes up other goes
up. Seeming to suggest that whining and talent are inversely correlated. Like I said, it doesn’t establish causation but the correlation is very clear of the graph if
you just give it one glance. The whole – what you don’t like with your manager or organization is an opportunity to whine – the talented programmers who take little
time in solving the code puzzle also take little time on this question. The ones who whine and spend long time in whining tend to spend equally long time in solving
simple code issues. Like I said, the sample size doesn’t qualify it to be a real research but if you look at the graph closely the correlation should be pretty
evident.
rajiv
Total time: 30 seconds - mainly because I double-checked for typos.
But here's the more interesting challenge: identifying all of the reasons why this straightforward answer might not work. Reflecting on the question more deeply
reveals some potential problems - some of which may make this challenge literally unsolvable.
Catch #1: Presumably, we're talking about code in the middle of a function - but if not, there are problems. In many curly-brace languages, including ANSI C and Java,
code cannot exist outside of a function body (notwithstanding comments and preprocessor directives like #include, #const, etc.) So if we're required to start with that
code, with nothing before it... then the code is uncompilable. Scripted languages like JavaScript are more tolerant, but "int" isn't a valid JavaScript keyword. Python
is similarly duck-typed, and also uses a more plain style in for loops, so... what language are we using, exactly?
Catch #2: There's no indication that anything like
stdio.h even if you don't specify it manually, but others won't. And I'm really unsure whether #include preprocessor directives in the middle of a function body are
allowed... at the very least, it's very unusual. Likewise, if the toolchain doesn't link to both stdio.h and stdlib.o, those resources won't be available.
But if those types of considerations are taken off the table... then, yes, any self-respecting programmer should be able to answer this question correctly within very
short amount of time. 10+ minutes without an answer: the interview is over.
{
if (i >= -100 and i <= -1) print(-i);
if (i == -1) break;
}
work or goofing off, but not in an interview.
The last half dozen times I interviewed for a job, I was employed at the time. I aced the technical questions. Before that, I was getting hammered by the costs of
having two kids in daycare and then got laid off. I botched interview questions that I could have answered in my sleep a month earlier. But the pressure was on, I
was desperate to make a good impression, and as a result I botched four interviews in a row before I calmed down enough to demonstrate my knowledge.
I wouldn't ask you or anyone else to change your interview processes as a result. Without telepathy, you have no way to know whether errors come from anxiety or
incompetence. But it does skew the results of your test or the FizzBuzz test to make the state of the industry look much worse than it actually is.
for (int i=0;100+i>=1;i--) { System.out.println(100+i); }
It seems more intuitive to me because it clearly decrements and also clearly shows the "hard stop" at 1 that makes it easier to avoid an off-by-one error.
Don't tell me I can't count downward!
conducted the interviews (which I assume is the order the values are presented in) only serves to obscure the point you're making.
need to include
public class untitled {
public static void main(String [] args) {
for(int i=0; i < 100; i++) {
System.out.println(100 - i);
}
}
}
I never cease to be amazed at how incapable people are of being able to see outside of themselves and their own bubble, unable to see anything beyond their own
circumstance. As one example, I am in every way a senior developer. I have been writing code since the mid-80s and have been doing it professionally (and morning,
noon and night) since the late-90s. I would currently consider myself a senior-level C# and JavaScript developer (both with the languages themselves and the
ecosystems around these languages). There was a time I would have qualified as senior-level in Java, PHP and Clojure, though due to less usage in recent years I would
call those intermediate-level competence today. I would also consider myself at an intermediate-level with Python, C++ and F#. I have vast database experience, both
relational and the various non-relational stores, with a clear understanding of which best fits any given scenario. I have led many development teams and designed and
developed many solutions in large-scale and complex problem domains. Not an attempt to be arrogant, but if you think you are more experienced than I in any way, odds
are you are probably wrong.
Why am I listing all of this? Because even with all of this knowledge and experience, I fall flat on my face in interviews. Eventually, after 5 or 6 interviews in a
short period of time, I get back to being able to display some semblance of competence in an interview. But those first few are train wrecks. In one interview, I
could not get myself to remember how to instantiate a string in C#. I literally could not do hello world. I have ended a few interviews mid-way through because I
could not answer simple questions. I have turned in blank papers full of brain teasers.
The point? I know you think you are special, and one of the most capable out there of discerning talent. Unfortunately, you're probably not. And maybe you should
pause when you find yourself declaring the incompetence of everyone outside of your little world.
@Mark - Programmers are people, and typically need to work in a team, and communicate with that team. They may need also to communicate to other human beings. The
ability to answer questions under pressure could be seen as a pretty basic skill that an employer might want them to have. A programmer who has a huge amount of
technical experience but can only operate to a decent level in a pressure-free environment isn't likely to be in high demand. It's a perfectly reasonable criterion to
apply: must be able to answer programming questions in an interview, because we need them to do the same for customers, other team members, senior devs from other
offices, junior staff who need some guidance, when there's a deadline- you know, most of the time
not sure what that says about me as a developer. :-)
I feel for your employees if, as you make it sound, you regularly put them in pressure filled situations where they must answer random questions for you or lose their
jobs. As should have been clear from my post, I have no problems with communication. I have no problems meeting deadlines under pressure. I have no problems
navigating the political waters that are a part of every project. I have no problems working within or leading teams composed of varying experience levels. The
overwhelming majority of the (many, many) people I've worked with and collaborated with over the years would consider me the best they've worked with.
What I do have problems with are interviews. As I've stated, I've been in this game a very long time, and I have yet to come across a situation in any project where I
was faced with the requirement of answering a random question or I would lose my job. That is essentially what an interview feels like for some of us: spit the right
words out of your mouth in a short period of time while everyone is watching or you lose. If that is ever the situation on the job for your employees - ever, much
less the daily occurrence you make it out to be - I truly feel sorry for your staff and would urge them to look for better employment.
explain why.
You wrote "The ability to answer questions under pressure could be seen as a pretty basic skill that an employer might want them to have. A programmer who has a huge
amount of technical experience but can only operate to a decent level in a pressure-free environment isn't likely to be in high demand. It's a perfectly reasonable
criterion to apply: must be able to answer programming questions in an interview, because we need them to do the same for customers, other team members, senior devs
from other offices, junior staff who need some guidance, when there's a deadline- you know, most of the time."
This is all true, but I would like to point out that many times an interview situation is a far _higher_ pressure situation than any I have ever encountered in the
workplace, and that is after 25 years of professional experience in a number of different companies, delivering code under occasionally very high stress situations,
with extreme deadlines and overtime, people's jobs riding on me, sometimes bosses freaking out, etc.
In a work situation like that, you have at that point relationships with your co-workers. They may be difficult relationships. You have a track record. It may not be a
great track record, but these things are known quantities. You may be at risk of losing your job, or other people's jobs, if you screw up. That's a lot of pressure.
I've been there a number of times, and did the heroic development effort (or failed at it, or mostly succeeded), and it had whatever results it had (often saving the
project with a personal heroic effort utterly fails to save the company in the long run).
In an interview situation you may be in far worse shape. If you're not in a location with plentiful jobs, and you have a house you can't sell, and a family, and you've
been looking for work for a while, and you're over forty, the stakes can be MUCH higher. You may be on the verge of missing mortgage payments. You may have blown
through your 401K retirement savings. You may be running out of unemployment benefits. In short, you may be on the verge of being homeless and/or unable to support
your family. Your marriage may be under extreme stress. Your relationships with other family members (perhaps those you've borrowed or accepted money from) may also be
under extreme stress. You might be having a hard time getting interviews. So when you have one, there's a lot at stake.
I had this happen this year. I usually interview quite well. I had a Skype interview where there were three or four people on the line I couldn't see, and they asked
me to write code on a shared whiteboard app while they watched. It was a really simple piece of C code; a string reverse. I had done it before in interviews. This job
was a very promising job that was in commuting distance of my home. I choked completely.
I realize you have no reason to believe me when I say I'm a competent developer, but I assure you that I can reason about code and solve programming problems in a work
environment quite well. I've been on the other end of the interview, too, having managed developers and interviewed developers. But anyone can choke in a stressful
enough circumstance. Performing in front of strangers you can't see when your mind is racing about whether you will be able to pay the mortgage, or have to tell the
family we are losing our home, is one of those. It's a lot more stressful than even the most stressful work situation once you're in a job. Worse, when I told them I
was choking at it, none of the people in the call had anything compassionate or helpful to say at all; they were just silent. And I knew they were probably thinking
that my resume and career was somehow a fraud.
Please consider the plight of real people struggling in the real economy before you spout off so glibly about how a developer choking in a stressful interview
situation is a developer who "can only operate to a decent level in a pressure-free environment."
This works only in Java. In C, C++ and D, that's undefined behavior, only unsigned types have defined overflows. In C#, it crashes with OverflowException.
Oh come on... the correct answer is: for(i=0;i<1;++){ printf "100 to 1";}
been a far more accurate tool for the job.
and fail to solve simple problems.
Enumerable.Range(1, 100).Reverse().ToList().ForEach(Console.WriteLine);
for(int i=0; i < 100; i++)
std::cout << (100-i) << std::endl;
// For c 2 lines,
for(int i=0; i < 100; i++)
printf("%i\r\n", 100-i);
Anyone doing negatives and overflows should be kicked in the head. lol..
"for(int i=0;" and continue from there
This means you finish it by adding a range. not literally leaving it blank after i=0.
for (var i=0; i < 100; console.log(100-i++)) {}
near morally reprehensible given the way you're lording over the subject matter and your condescending responses to other readers. Frankly, I think you owe your
readers an apology, not for expressing a valid opinion, but for your complete and total abuse of statistical reasoning and analysis. The level of incompetence
exhibited here is so high that I'm led to believe you couldn't have knowingly attempted to spin the data for your own personal gain. If you plan on continuing to
publish such material, for your reader's sake you should seriously consider enrolling in a college-level statistics or experiment design class, regardless of whether
you completed either class previously. In any case, next time please try to be more responsible with your existing knowledge. I promise you will sell more books in
the long run that way.
It's a pity that the sample size is way too small for any real conclusions - but I think you might be on to something.
I think you might see this pattern over a large sample size as well. But I suspect one of main correlating factors will be that crappy organizations tend to have poor
programmers, great organizations tend to have good programmers. In my experience this is a VERY strong correlation. And if you get the first question when you are in a
crappy organization then it will naturally take a lot of time and brain focus.
That being said - if not ALL programmers can solve this problem in less than 10 minutes under different circumstances, then we are in serious trouble as an industry.
show, but the relevant details in the data were still obscured.
Essentially, you're trying to show a correlation between two dimension of data.. This is what a scatterplot was made for!
for($i=0; $i += 100; $i -= 101) {
print $i ."\n";
}
When $i = -100, $i += 100 will return 0 and the condition will return false, ending execution before printing 0.
the barrel, the kind of "programmers" who keep applying to jobs and keep getting rejected.
The good programmers have a job. And when they lose it, they get a new one in one or two interviews. Most of them never go through a jobs site, they already get
hassled by recruiters regularly.
So your problem is not with the fact that most programmers suck, it is with the fact that the recruiter for your sample had no idea how to find good programmers *or*
that the company said recruiter works for is incapable of attracting good programmers.
for ($i=0, $i <= 100, $i++) {
echo ($i > 0) ? $i : null;
}
Quick and dirty, but prints the task.
for ($i=0; $i <= 100; $i++) {
echo ($i > 0) ? $i : null;
}
taken longer!) Got it right the first time around, but I attribute that to no pressure.
So my PowerShell solution was (which would have been almost identical to my C# solution):
for ($i = 0; $i -lt 100; $i++)
{
Write-Host (100 - $i)
}
However PowerShell you could even just do:
100..1
and it would print 100 down to 1 in the console!
I agree with others though that some people will be under stress regardless of how casually the question was put to them because they are currently the subject of an
interview, and this will negatively affect some people's ability to solve the problem on the spot.
for (int i = 0; i < 100; printf("%d\n", 100 - i++)) ;
@Alk
The requirement was 100 to 1 and you printed 1 to 100. No job for you ??
for(var i = 0; i<100; i++) console.log(100-i);
@Mark, and @Paul -
First, I didn't write this article. Just sharing my thoughts.
Internet arguments suck. You can take words and twist them exactly as you please to make your point valid. (I could do that too, of course). You'll have to do
better than "I feel sorry for your employees if you regularly put them in high-pressure situations", though. That's stupid!
Clearly as people who admit to having a problem in interviews, you have a non-neutral viewpoint. As do I, of course, but you are so on the defensive about this it's
visible from space.
My point was, performing well in an interview demonstrates skills which can be transferred to other aspects of work. It's not a negative if you do well in an
interview, it's a positive. It's not a positive if you choke in an interview, it's a negative. Those 3 points combined are what I'm saying: it is a positive if you
perform well in an interview, which also demonstrates other skills which may be important to a role.
Each company's assessment of this will vary greatly. It should surely depend on the role too. A nervous junior is going to get a lot more leeway. But a role
requiring managerial, strategic, or other real-world ancillary work-life skills? Well, keeping cool in an interview situation demonstrates a lot of skills which align
with that role.
Can I has job?
Regarding internet arguments, I agree, but unfortunately the same issues are true in real-life arguments [see any public debate ever]. People key on a small subset of
points or words and ignore the rest of the other side's argument, and you have done the same thing as I have.
Regarding defensiveness, yes, of course I get defensive when it is implied that if one chokes in interviews then it necessarily follows that they are incapable of
excelling in software development. Similarly, if you had implied that if one is not a white or asian male then one cannot be a competent developer, I would expect
those that are not white or asian males to be defensive. Taking an aggressive stance and speaking with certainty about uncertain things will always put some people on
the defensive.
My point is, determining how a person will work out as an employee from a few short interactions is very difficult. The problem is, people don't like the uncertainty
of reality, so they do what you are trying to do and boil the formula for success down to a few key factors. Couple that with the hubris of most people who spend a
lot of time on the hiring side and that formula for success becomes divine law because they have built their careers around this formula.
For some jobs, absolutely, choking in an interview likely indicates a good chance of failure on the job. Interviews are essentially high-speed sales. You are given a
short period of time and asked to convince strangers to buy your product. This directly correlates to on-the-job skills for sales teams, and as you stated, can
correlate fairly well with many managerial positions. Not software development.
You might make the argument that sales is the same as influencing a team with diverse goals to follow one path. I would argue that in general, it is a very different
thing than selling to strangers in a short interaction. You build up rapport with your team over time, they see you consistently working hard, they see the quality of
your work and appreciate when your work makes their lives easier, they see when you go the extra mile in tough times, they come to respect you and trust your decision
making, and thereby trust your recommendations and trust that you have everyone's best interests at heart. To me, this is a very different thing than sales to
strangers.
I'm not disagreeing that by using a formula you can mitigate risk and weed out a lot of potentially bad candidates, but you will also weed out a lot of potentially
great candidates in the process. Look, I have also been on the hiring side of the table a few times, and I may have been too forgiving of candidate errors, but the
reality is hiring is hard, Predicting the future is hard. Seeing the world from another's perspective is hard. These are all, however, things we need to do from
time to time.
go out to you. But that doesn't change the fact that people making hiring decisions need some kind of metric to go by, and a very good metric for determining whether
or not a person can write code is to ask them to write code. Similar metrics are applied for any other types of skilled employment positions, as well as for things
like gaining acceptance into universities. It is your responsibility to demonstrate the appropriate level of knowledge and experience to be hired for the job. It is
the hiring manager's responsibility to choose the person they think best demonstrated the appropriate level of knowledge and experience for the job. And as the old
adage go, actions speak louder than words.
for (int i = 0; i < 100; i++)
{
System.Diagnostics.Debug.WriteLine((i - 100).ToString().Replace("-", string.Empty));
}
Ouch. It just hurts. So close but so far away. 100-i ! If you really wanted to do it i-100 atleast use Math.Abs() instead of string manipulation.
for (int i = 0; i < 100; i++) Debug.WriteLine((i - 100).ToString().Replace("-", string.Empty));
for (int i = 0; i < 100; i++) Debug.WriteLine(Math.Abs(i - 100));
for (int i = 0; i < 100; i++) Debug.WriteLine(100-i);
All return the desired result and solve the problem, but only one is "maintainable". My coworker looked at the problem and expanded on it and said "What if you need to
print 100 to -100?" The obvious answer is now:
for (int i = 0; i < 200; i++) Debug.WriteLine(100-i);
The other two fall severely short when additional parameters are introduced.
for (int i = 0; i <= 0; i++) println("100\n99\n98\n97\n96\n ... 1\n");
public class Program
{
public static void Main()
{
for(int i = 0; i < 100; i++)
{
Console.WriteLine(val--);
}
}
static int val = 100;
}
But that "wait for overflow" thing in C? Signed overflow is undefined behavior! Please return your Software Developer Licence at the front desk and go back to Programming 101.
Then back to the arcticle. Very interesting results. Have you considered that making someone discuss their possibly horrible current workplace makes them emotionally so juiced out that their performance is lowered because of that?
PS. I solved it within a minute and am happy with my current workplace :)
for (int i = 0; i < 100; ++i) {[newline and 4 spaces]printf("%d\n", 100 - i);[newline]}
He is actually correct as it completes the task but I am not sure why he used Debug.WriteLine. He was having fun with the task because the easy and efficient answers is obvious. If a coder can not comprehend using 100-i and counting up then they are just programmers. They know syntax and can troubleshoot the syntax errors and implement logic from others.
Then you have Coders... people who understand logic flow to answer problems and use code to implement their solution.
If you still think its wrong, go run this code:
for (int i = 0; i < 100; i++) Console.WriteLine((i - 100).ToString().Replace("-", string.Empty));
This solution is also O(1)
for (int i=0; i < 100; ++i)
printf("%d\n", 100-i);
for i in range(1, 100):
print (100 - i);
c++
void main()
{
int j = 100;
for( int i=0 ; i < 100 ;++i --j)
std::cout << j << ' ';
std::cout << '\n';
}
The programming problem you pose is a bullshit gotcha question (and yes, I solved it in less than 2 minutes with the 100 - i approach). It tells us nothing about
knowledge, experience and ability to perform the job under typical working conditions. The job of software development is not some game show where one has to recall
bits of trivia on a split-second notice in order to win the prize. Yet you place an inordinate value on the ability to work out a solution without providing the
environment or tools typically used when performing the job.
Furthermore, what you're actually testing is arithmetic, not programming. Any programmer can write a proper loop but that's not really the key to this solution. Its
not unusual for even experienced people to have a little difficulty working out arithmetic in their heads, particularly in a high pressure situation such as an
interview. Given a REPL or a compiler and debugger (none of which I have ever been offered in these live programming "tests" I wouldn't be surprised if most, if not
all, of your candidates solved the problem in a reasonable amount of time.
And there's something else, and I have conducted many technical interviews myself so I know this for a fact, you're discounting the bias of having worked out the
solution yourself beforehand. How long (and how many tries) did it take you to solve the problem when you designed your interview? Things look very different after
you've worked out the solution while under no pressure to provide a timed response in an interview than being presented with the problem for the first time in an
interview. And this bias gets worse with every repetition.
Finally, your comparison of "whining time" with problem solving time is hacky and completely unscientific. This article makes you sound like the biggest whiner of all.
You haven't demonstrated some kind of fundamental problem with programmers interviewing for jobs. All you've demonstrated is that you're a self-important douche bag
who hasn't got the slightest clue as to how to evaluate potential employee's knowledge and experience.
- on a keyboard, with no pressure, and after having read the question calmly. Asked verbally, I would be wondering what inputs I was expecting, what exception cases
the user might introduce, and other issues that aren't relevant to the problem, because no program is ever this simple outside of a classroom. Wrong mindsets produce
wrong results, and your real programmers have a mindset that is narrowed to solving real problems.
You're also taking it out of familiar context. I worked as a MSSQL DBA for a while before getting back to programming, and my first interview after that they asked me
to create a pivot query in Access. They stopped me when I gave up on the GUI and went to the SQL view and the interview was pretty much over right there.
And modern best practices don't lend themselves to this problem. Few good programmers type For Loops anymore. Most use tools that pre-fill these simple commands so
they don't have to be thought about repeatedly. I type "for", then hit tab, and I get "for (int i = 0; i < UpperBound; i++) \n{\n \n}", with UpperBound highlighted to
type over, and a tab stop waiting for the next part between the squiggles. Instead of taking seconds to solve and type it, I type the solution faster than I can even
think through the basic "for loop" structure. As such, I might stumble hand-writing out the for loop, putting the wrong inequality, putting the bound after the
increment, or stopping to try to figure out what output is valid in the utter lack of context the question gives, before I even get to only problem solving of the
question, subtracting the iterator.
Where I work, we solved this problem by giving a longer, written test where the programmers could use time to get past the mindset problem without us glaring at them
across a table. We also ask some questions that fit more with what we expect them to do in the job - things like taking provided data and returning it in a specific
way that will hold up if the data changes.
{
$array[] = $i+1;
}
print implode("\n",(array_reverse($array)));
?>
Yes Josh, the AWS server went down from Reditt's Hug and for some reason lost it's disk state for the last couple of days. We had to restore the comments from a backup source. Really sorry about that.
public class Interview {
public static void main(String[] args) {
int i;
for (i=0; i<100; i++){
System.out.println(100-i);
}
}
}
for(int i = 0; i < 100; i++)
cout << 100-i << "\n";
I dunno what makes me sadder... That people can't answer this simple question, or that people like Scott Turner above solve it in very convoluted ways, or that more people are using Java than C++...
Hell, even my first semester students were able to solve it simply and elegantly unlike many people here.
Comments are closed.