You'd hire a developer who trusted the method name as a reliable means of determining what the method was supposed to do?
He also gave a little potted description, much like you'd expect to see in a comment:
"find the point in the list at which to insert the node (as the list is sorted - as in the method name) and then adjust the links. "
Plus it is pretty obvious from the code what they are trying to do.
TG I mean what kind of systems etc? Enterprise, embedded, game, what?
You'd hire a developer who trusted the method name as a reliable means of determining what the method was supposed to do?
pedantic...
obviously if it didn't then there is scope for the candidate to point that out. However in the introduction to the problem I have explained what it is supposed to do anyway, confirming that the method name is correct.
I basically try to be as handholding as possible and give the candidate as much help as I can - the good cop/bad cop part of the interview comes later...
All I want the candidate to do is identify that he would test if for the median case and the two edge cases - simple logical thinking...
He also gave a little potted description, much like you'd expect to see in a comment:
Oh yeah. I've just failed the aptitude test for failing to read the question properly. (-:
[i]Has anyone else started from scratch in software? I can see that its a complex job, but is there a timeframe you can possibly put on something like this at which you can just say 'Yeh, I tried, its obviously not for me'. [/i]
I started from scratch, +30 y/o 🙂
I've been in IT since I left school and IMO there are some people who get it and some who don't, but the vast majority, get [b]some[/b] of it...
Also how old are you, because for many people their ability to learn something new diminishes with age - ie once in your 40's it drops off.
Aye, if you're working in an environment with a comprehensive set of unit test
Surely if you are working in an Enterprise Java environment, and environment which is tool rich, then it is a pretty big flaw if you have produced a system that isn't...
Surely if you are working in an Enterprise Java environment, and environment which is tool rich, then it is a pretty big flaw if you have produced a system that isn't
Depends on the project 🙂
On this one, if we'd spent the time producing comprehensive unit tests we'd have still had defects, but we'd have missed our deadline by months and incurred huge penalties. We only had time for basic unit testing.
All I want the candidate to do is identify that he would test if for the median case and the two edge cases - simple logical thinking...
Yeah, that's the problem isn't it. I don't really understand linked lists or the syntax around them, it's 20 years since I last did anything like this; but looking at it, I'd guess there may be an issue if the new node is the first in the list (as previousNode is null) or the last (as the while loop will _nextNode past the end of the list).
Am I anywhere near?
All I want the candidate to do is identify that he would test if for the median case and the two edge cases - simple logical thinking...
[img] 
[/img]
Am I anywhere near?
Yes, pretty much spot on I'd say. Two nasty null de-reference errors waiting to happen there.
Oh, that's brilliant. (the pic)
TG I mean what kind of systems etc? Enterprise, embedded, game, what?
At the moment it is a hosted 'messaging hub' - around 700 fund providers/distributors all passing STP messages to each other through us, using different (flavours of) protocols/transports.
Pretty simple design really. All in one of those hand-holding managed languages...
Previously various trading systems.
Complicated wise one nice component I wrote subscribed to reuters price feeds and also sniffed out new price 'chains', so registering them with the system and subscribing to them as the same time, so that was pretty heavily multi-threaded. Config guide I wrote was 55 pages long 🙂
Wrote a compete Fix engine at UBS as QuickFix wasn't around at the time - certified it with CME and others.
Many more things...
Java wise I wrote a JMS adapter for our system to bridge between our C# and a Sonic MQ system - carries 40% of our flow.
Also wrote a dummy exchange at UBS in Java - we called it the Black Market as the configuration allowed trading in Uzis and Cocaine 🙂
Most complicated big system I worked on was a a 3 tier distributed MM/FX trading system where the Kernel was (part) written by the Nick Hines, who was later the head of tech and MD at Thoughtworks (you must have read Martin Fowlers books...) - I later ported all the network layer from Netbios to TCP/IP and the kernel from OS/2 to Windows NT, and rewrote most of it in C++ instead of C.
As he says - once you had worked on that system, everything else is easy.
Is that enough context ?
Am I anywhere near?
yes, and I would have done my best to coax you to the point of those answers - I am not so worried about not knowing the language as that can be learnt easily later if needed.
As pointed out earlier - if you think in the right way and can identify that the edge conditions need testing in the above, then you could contribute usefully in a paired environment whilst picking up any tech skill needed on the side.
Ah yes.. trading and financial transactions.. that explains it.
On this one, if we'd spent the time producing comprehensive unit tests we'd have still had defects, but we'd have missed our deadline by months and incurred huge penalties. We only had time for basic unit testing.
that is completely wrong thinking - you really don't get how modern development is supposed to work.
Spending the investment on the tests up front has the massive benefit of producing a stable system fast.
Try ready the XP explained book for a flavor.
I produced a gateway for our Superstream offering a couple of years ago - we were late to the party but (the management) had committed ourselves to a group testing deadline, and the company that was going to supply the engine were trying to screw us for a shed-load of money.
One of our guys came up with realistic deadlines for writing our own gateway, but it was a long way past our deadline.
I stupidly said 'let me have a go' and ended up working 14-16 hour days, 7 days a week, for about 3 months.
Hit various nasty technical issues, like MS not supporting soap-with-attachments, required security protocols not supported, etc. Net Reflector to the rescue...
Obviously I was really tired towards the end, but I had arranged the database design and configuration file topology such that I could use nunit to orchestrate the integration tests allowing me to fire up several gateways within one test and test passing messages around and testing the message content.
If I hadn't have risked that investment there is no way I could have delivered anything stable, or with the required functionality. As I developed functionality the system remained stable as I would catch the errors I introduced because I was tired, or when I had to significantly refactor something to support new functionality.
I see this pattern repeatedly, in my work and others.
Using excuses like yours is a sackable offense in my book...
Loving that photo GrahamS!
@ OP : I've been in IT for 10 years now, mostly rising up through the ranks of Windows SysAdmins (pretty GUI, point 'n' click, etc). Never really [i]needed[/i] to learn a programming language, I could always understand sufficient (from examples, books) to get a task done.
Now I've moved into DevOps (Linux only), I have been required to learn - from scratch - a new language/framework (Chef / Vagrant) which is critical for my job.
I found a few different eBooks online, and only really got on with one - so purchased a physical copy to digest ( Learning Chef: A Guide to Configuration Management and Automation - by Taylor & Vargo).
Finding the right teaching materials that works for [b]you[/b] is key.
Good luck!
Ah yes.. trading and financial transactions.. that explains it.
wtf does that mean ?
that you don't have to have any technical depth if you work on EJB stuff ?
Has anyone else started from scratch in software? I can see that its a complex job, but is there a timeframe you can possibly put on something like this at which you can just say 'Yeh, I tried, its obviously not for me'.I started from scratch, +30 y/o
Same here - we were lucky as it has been a gradual introduction to what we have now, so we learnt 'from the ground' up, or from 'first principles'.
I feel privileged to have learnt from K&R, Stroustrup, Barbara Moo and Andrew Koenig, Jon Coplien, etc.
what doesa = a + 1
mean to you ?
Are we talking BASIC or C++ operator overloading?
Could be just about anything if the latter.
wtf does that mean ?
Well I've never worked in that area but it seems fairly low level with stringent performance requirements and a particularly high cost of failure, so a good place for nitpicking geeks.
If you are using high level products and tools, it's not that you don't need technical depth, but it's in a different area. What little code there is should be very simple and very obvious. The complexity comes with the interactions between various products and how they operate. There's a lot of subtlety and detail in the design, much less in the code.
It's faster you see, because the computery thing doesn't need to spend so much time reading.
You laugh, but I still write software the way I did when I was programming my Commodore 64, when that kind of thing mattered 😉
I can't even work out how my own code works, sometimes. This is perhaps why I'm better at building bikes.
that is completely wrong thinking - you really don't get how modern development is supposed to work.
The deadlines are imposed on us, we don't supply them.
Using excuses like yours is a sackable offense in my book...
And yet here I am, successful and capable. Good job we're not using the same book* eh? 🙂 We are on course to deliver, btw, and our system works. Despite the lack of comprehensive unit test coverage.
* for the reasons outlined above. Different areas require different books.
that explains it.
??
I've been a software engineer since 1997 and my background includes such varied things as oil industry applications, mobile phone network QoS, blood glucose meters, cash machines, automotive control, MRI scanners, cow monitoring(!), and secret squirrel shh-shh stuff.
I've been up and down the stack from high-level stuff (Business Objects, Oracle, SQL Server, OLAP, Java, Spring, AJAX, XML/XSD etc) through middleware stuff (AMQP, SOAP), and a lot of low-level stuff (microprocessors, embedded devices etc).
I think the test TG set is pretty reasonable.
[b]Edit[/b]: you've explained yourself while I was thinking about my CV 🙂
Well I've never worked in that area but it seems fairly low level with stringent performance requirements and a particularly high cost of failure, so a good place for nitpicking geeks.
Yep, a lot of the stuff I do is technical, safety critical and needs to meet stuff like FDA, MISRA, MilSpec, ISO standards.
Which may be why I see TG's side here.
I think the test TG set is pretty reasonable.
As said - it can work well, sometimes it doesn't.
If you haven't got time to create unit tests, what do you do? How do you meet that challenge?
That photo should be the interview test. Anyone who laughs gets it 🙂Oh, that's brilliant. (the pic)
Just to clarify - I'm not saying that TDD or unit testing is a bad idea. I'm saying that the best approach depends on the project and the situation.
Don't like the look of the while loop termination condition in TG's test 🙂
Got null pointer exception written all over it.
If you haven't got time to create unit tests, what do you do? How do you meet that challenge?
You can either spend time writing tests or time in maintenance trying to figure out bugs.
The latter tends to exceed the former.
If you [i]really[/i] can't test everything then you test at the boundaries/interfaces to make sure you can at least have some confidence in how it all hangs together. (plus that gives you some power to refactor)
You can either spend time writing tests or time in maintenance trying to figure out bugs.
The latter tends to exceed the former.
So you're given a fixed amount of time in which to complete a project. You don't tihnk it's enough - do you just refuse to do it?
Remember, I'm talking about comprehensive unit test suites. Functional and integration testing is still in.
So you're given a fixed amount of time in which to complete a project. You don't tihnk it's enough - do you just refuse to do it?
The Agile way is to sit down with the [url= https://www.mountaingoatsoftware.com/agile/scrum/product-owner ]Product Owner[/url] and decide which features or User Stories they want to ditch so you can hit the deadline.
The premise is basically that a system with the top 80% of the requested features that works 100% is a much better product than a system with 100% of the requested features that works 80% of the time.
The deadlines are imposed on us, we don't supply them.
and you write the unit tests to ensure that you meet the deadlines with a stable system, and also don't over-engineer the solution to the problem.
That is just such a poor excuse for someone who works a a world of supposedly good practice, such as Java and EJB.
Just about all of the modern testing toolsets were first available in the Java environment.
You are just kidding yourself. Spend the time on learning how to use these tools to make your life easier.
I have worked in a lot of institutions with unbelievable levels of incompetence (it seems investment banks value it...) so the fact that you continue to work in that antiquated way doesn't surprise me.
These test frameworks are successful because developers don't like testing, but in this case they are writing code to do the testing so that compensates.
Plus there is a level of sophistication in using these test, ioc, mocking frameworks that also appeals.
And lastly, as I said, the tests and the assertions in the good test names, are a good form of documentation and knowledge sharing.
If you haven't got time to create unit tests, what do you do? How do you meet that challenge?
IMO - unit tests can add some upfront cost to the timescales; however they are rarely in themselves a reason why timescales slip. Dev's don't always get the tests correct - anyone who claims to write bug free tests; might as well claim to write bug free code and be done with the tests after all 🙂
I'm not the biggest fan of TDD though; there are times when it's use is appropriate and times when it's not. And nothing puts off a competent developer from moving over to a TDD style of development than being evangelised at by a TDD-to-deather* who thinks anyone who doesn't do TDD is inferior. It's not a golden 'this will make your code good' saviour; and it can't replace intelligent people who can think carefully around a problem and create well structured; well thought out maintainable code.
*anyone who's worked in an agile environment will know the type
Sorry - this thread seems to have been derailed slightly !
Could you give us an example or two of something you are struggling with - maybe some mocked code / modified and an outline of what you are trying to achieve - I wouldn't expect you to copy and paste actual source code from your repository here - but if you can give us an idea we might be able to give some pointers* on how it could be approached ?
Steve
Plus there is a level of sophistication in using these test, ioc, mocking frameworks that also appeals.
This is another interesting aspect. If you know you will be unit testing stuff then it encourages lots of good healthy design/programming principles (loose coupling, IoC, [url= https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 ]SOLID[/url] etc) that make the resulting code better.
You are just kidding yourself. Spend the time on learning how to use these tools to make your life easier.
No, you are not understanding me.
I've written bloody thousands of unit tests too.
so the fact that you continue to work in that antiquated way doesn't surprise me
You just don't understand my point. I don't 'continue' to work in this way. I work the way that the project demands. Projects of which I am not in charge, incidentally.
Instead of denouncing me as incompetent, you perhaps should've asked me to explain myself and listened. Glad you're not my boss 🙂
I'm not the biggest fan of TDD though; there are times when it's use is appropriate and times when it's not.
Bingo.
a TDD-to-deather* ...*anyone who's worked in an agile environment will know the type
Yeah they are often seen name dropping all over the place 🙂
If you know you will be unit testing stuff then it encourages lots of good healthy design/programming principles (loose coupling, IoC, SOLID etc) that make the resulting code better.
You *should* be doing that anyway.
So you're given a fixed amount of time in which to complete a project. You don't tihnk it's enough - do you just refuse to do it?
It is like stepping back in time a decade or so - I thought these arguments were over 🙁
As a developer with a fixed amount of time I have to think which is the most likely way to meet that time frame.
I need to do comprehensive analysis on the problem to ensure I have everything covered. That comprehensive analysis will normally be an identification of the various use cases that I have to meet.
I figure out how I am going to address each use case, and how I can prove that I have addressed it.
Ideally I want to automatically prove that I have met it.
In order to do this I need to architect my solution so I have testable components - which is one of the strongest arguments for TDD, it forces you to produce a well decoupled system so that it can be automatically tested.
I then have a list of tests to meet - I can measure my progress based on the number of tests passed.
It takes discipline and the trouble is that it can be too late to go back and impose the testable design once you have started building a system.
But it can also be difficult determining everything that needs to be tested without having written some code and gained experience of the domain. Catch22 a bit.
Anytime I have rushed in I have regretted it - but anytime I put the upfront investment in to produce a highly testable system I haven't, I have been grateful for it as it has massively helped me produce a stable system to time.
If anything, not having the tests is by far the riskiest proposition as then I am facing the possibility of not being able to meet a deadline because of the number of issues I have to clean up, which would have been caught by the tests.
Read this book for the use case analysis - it is excellent and you won't find a more lazy programmer than me :
But it can also be difficult determining everything that needs to be tested without having written some code and gained experience of the domain. Catch22 a bit.
The value of spikes; hack some code around to figure out what/how something needs to be done. Then write tests from the knowledge and then implement.
Academically pushing the TDD principle is not helpful.
Unless you are a domain expert you can't necessarily identify all the things to test in the first place.
So whereas TDD might be an ideal, you might have to be pragmatic about it. And you might even have to 'start again' once you have written some code to explore the problem.
So test coverage is more the ideal to strive for.
But there is a big risk of ending up with stuff that is not testable if you start coding early, and not being able to come back from it. The more untestable code there is, the more the risk of project runaway.
I read a Dependency-Injection book the other month and he was designing his system top-down within the Ioc Container, which seemed a good idea.
He was ending up with a production-ready prototype that was runnable in the test framework.
I'm not writing java, incidentally. Or any other 'language'.
I have no way of creating what you would describe as unit tests.
I read a Dependency-Injection book the other month and he was designing his system top-down within the Ioc Container, which seemed a good idea.
Absolutely - and agree on the academic pushing of TDD.
The reality is that some people write well structured testable code; with good IoC principles; SOC and all that stuff and never go near a unit test framework.
And some people evangelise about TDD and write terrible code.
And every combination in between 🙂
Out of interest then ... what do you write in ?
For reference; I'm principally a C# guy theses days; but also use Ruby (we used this as a basis for a DSL that we created) and Java.
You *should* be doing that anyway.
Indeed, but most of that good stuff doesn't give an immediate payoff, so it is easy for it to get pushed aside as people hack stuff together for a deadline.
But if you are writing unit tests then a good design immediately pays back with easier tests.
I'm not writing java, incidentally. Or any other 'language'
What [i]are[/i] you doing then? Colouring in?
I am currently doing a form of delcaractive programming, as opposed to the usual procedural languages. So testing has to be scenario based. It's quite hard to explain to people who only think in traditional procedural terms, or whose organisational rules are set up along those lines. So you get beaten with this unit test stick a lot, which is why I have learned a flexible approach over the years. Not at the expense of quality, of course.
You need to choose the right approach for your project - not what the books tell you is right. But you still need to read them.
I am currently doing a form of delcaractive programming
You're doing SQL ? Why didn't you say 😉
Seriously though - a bit more information might be nice - what tools etc. That came across as a *little* condescending.
