« first day  last day (14 days later) » 

00:00
Not for this sort of work explicitly, not really, no.
Alright, just wanted your opinion, thanks man
I have general advice though.
Given that the position is related to testing and requires/recommends programming knowledge, ask about automated testing.
Half the candidates won't even be aware of automated testing probably.
Also, don't come in dressed up any more formally than you'd be comfortable working in every day.
That's interesting, why is that, out of curiosity?
Well, that's just my personal mantra, I guess.
If you really, really want/need the job, then dress to impress, I suppose.
But I personally don't want to work for a company that is more concerned with what I'm wearing than what I'm saying.
I don't underdress or come in grungy. I wear blue jeans & a polo to interviews.
Or sometimes a nice long sleeve shirt, depending on the weather
I see. Was just going to wear regular slacks and casual button-up
I'm more interested about automated testing though :)
00:08
oh
(I was though asking about the dressing just then)
I'd ask about it because either... a) half the candidates won't know about it and if the company uses it, you'll stick out, or b) the company doesn't use it and won't know what you're talking about (or will have an excuse why they don't use it), so you can know to just run away.
I see, OK. Now, aren't tests like that usually more on the QA level, or am I not seeing the dev structure correctly?
Automated tests are the first thing that should be done.
In fact, often tests are written before the code they're testing is written.
It's called "test-driven development"
Huh - That's neat
Is it where you basically write your specs into the tests, and then write the code afterwards that way you know it's up to specs from the beginning?
00:19
Essentially, yes.
Like, say we have a method that's supposed to return 2, no matter it's input.
And we know what we'll call the method, so we can write a test
(excuse the syntax)
func testTwoBox() {
    assert(twoBox(0) == 2, "Two box supposed to return two.")
    assert(twoBox(2) == 2, "Two box supposed to return two.")
    assert(twoBox(10) = 2, "Two box supposed to return two.")
}
We could write this test before we write twoBox method.
OK that makes perfect sense
And now as the method is being developed, it has to pass this test before it can be committed into source control.
Which means you can modify it all you want, but you have to test it before it gets committed into development.
By the way, wanna cast a close vote here? codereview.stackexchange.com/q/97521/36366
Done
Did you have a decent experience in general working in Microsoft C#/SQL stack?
Well, I like MSSQLServer.
I wasn't working with C# that much. I had to suffer with VB.
But it was all right.
Oh. Yuck.
00:26
I mean, to me, they're mostly all the same at this point.
I'm disappointed I upvoted that question. I didn't realize it was broken until I was part way through writing an answer.
And if it were just the case of a simple overlook and a minor bug, I'd let it slide. But this bug means that the whole thing simply does not work at all.
They're doing something fundamentally wrong I'm taking?
They're sorting by memory addresses.
No matter the contents of the variables a-e, it will always sort them in that order (by variable name) because I coincidentally created the variables with alphabetic names.
And because by coincidence, they'll almost always end up with ordered memory addresses.
So if you create them coincidentally in a way in which their contents are ordered, then no matter how you stick them in the array, sorting them by memory address and sorting them by contents are the same.
But because my example uses mutable objects, I can change the contents without changing the memory addresses. Attempting to sort again demonstrates that they're being sorted by their memory addresses rather than their contents.
I see, good bug catch
Well, thanks a lot for the advice and stuff, I do appreciate you
Need to clean up and shave and crap, maybe I'll get to work on concordance a bit hopefully

« first day  last day (14 days later) »