You interview a guy for a dev position and reject him. He asks if he can apply for the QA job, and you think he's qualified for it, so he gets it. A week into the job, he asks if he can do dev work. Will your response be:

This is a pretty common situation when hiring entry-level folks. If you need more devs, you'll hire more devs. You hired the QA guy because you need people to do the QA job and can't just let every QA guy who wants to do dev work do so.

That’s the kind of person you get to take time to evaluate him, back in the day QA to dev was a legitimate job path. But you tell the applicant they needs one year in QA before they’ll reconsider him so you get value out of the money you spent hiring him.

They hired you for a qa role, so they need that work done. Automating some of your tasks serves two purposes. It shows that you want to and can do some development. And two, it frees up your time to start taking on some of those dev tickets.

Thanks for the replies guys. I think it may have been missed that this is just a temporary (4 month) internship position that was arranged with help from my university. Therefore quitting isn't really an option. Also, I agree that it's probably way too soon to be asking for dev work. I'm still learning how to do what I was hired for.

It sounds like my only hope is to look for some opportunities to automate and maybe a month or two from now they'll give me some dev stuff to work on.

It's a bleak outlook though: I'm basically the only person doing QA in this company, so I get the feeling that it's unlikely that they'll allow me to do much else. Ah well. Live and learn.

Sent from my Moto G (5) Plus using Tapatalk

See if you can go to the standups and other scrum ceremonies of the dev teams you're working with. See how close you can work with the devs on issues you find, you don't have to make it a secret that you want to be a dev when you get out of school so see what they think of you trying to find the problem in the code, so instead of just giving the dev a trouble ticket you can give them were it's happening in the code. They may have never had QA who could find their way around a git repot so ask. Take as much advantage of the internship as you can, that's what they are there for.

My advice actually applies even more for an internship (depending on the company). We hire a bunch of 4 and 6 month interns and I try to give the really good candidates opportunities to work on something cool/interesting in the last month. Doesn?t always work out and not all places can do it - but excelling at the role is the best way to get a shot at a dev role next time.

Funnily enough, I?m probably closer to LL then most people. If someone proves themselves in less than a year and I thought they?d make a good dev I?d have no problem moving them up as fast as possible and not waiting for anything longer.

My disagreement with him here is that after only 2 weeks you don?t really know much more than when you hired them person.

ya exactly this. lets face, just about anyone with half a brain can do 95% of the QA work thats out there (the only exception being creation of automated testing that may not even exist or be under the purview of QA - we call them system test engineer).

forcing a dev to "learn and prove himself" at QA is just about the most worthless thing I can imagine.

I agree that forcing a dev to learn qa would be silly. But forcing someone you just hired to do QA do QA - seems like a no brainer.

if its an intern thru a university then I am absolutely throwing him some dev work and getting him a mentor.

Good advice. Fortunately, it is a very small company so I am getting to take part in dev meetings and getting some exposure to the general development process.

Also, FWIW they did mention at time of hiring that there would be some opportunities for me to possibly take part in some development work (towards the end of my work term), so I guess I'll just prove I'm really good at the work they've hired me for and keep my fingers crossed that they follow through on what they said.

If you wind up being a software developer, you will probably earn much more valuable experience doing QA for 4 months, than what you will lose by being 4 months behind as a developer.

Every dev should do QA for a while imo, to see the world from the other side. Just like every person should wait tables and teach for a few months imo.

Also a lot of us got our start building stuff on the side, which you can still do.

And the automation stuff. It's actually a lot harder to write good test cases than it is to write good code imo. You get good at that the code will flow.

That's very encouraging. There's no backing out now, so I'm committed to making the most of it.

In my limited free time over the work term, I'm a bit torn between learning a new language on the side (probably Javascript, because I noticed that many of the dev-related internships want this) and improving my abysmal (technical) interview question skills via CTCI/leetcode. I'm guessing most of you would advise the former over the latter?

Oh yeah, two weeks isn't long enough to see if they are good at anything but showing up to meetings on time.

Are you messing up the technical part or the talking at the whiteboard part?

I think mostly just the technical questions themselves. When I was interviewing for this internship, only two of the interviews had a significant technical component but I didn't perform well in either of them. I think it was mostly a case of lacking the knowledge/experience they were looking for, but since buying CTCI and trying some leetcode questions I've realized that I'm quite weak with these types of questions. I just finished taking an advanced algorithms class though so I thought it might be a good idea to start improving in this area now while the material is still relatively fresh. OTOH, maybe it makes more sense to just learn an in-demand language and framework for now and focus on CTCI/leetcode when I'm applying for my next internship.

I would like to supply the thought that finding whether a point is inside of a convex hull is a log(n) operation. If you don't see why this is true, I can explain.

Or, if you don't see why this helps, I can probably offer another hint.

(you are on the right track with the notion that if you can't draw a line between the hulls, then they must intersect)

Thanks that does help. My method right now for finding if the two hulls intersect is O(h^2) where h is the number of points in the hull but what you just said gave me an idea for the solution

Right, the segment-by-segment intersection will be h^2 which in it's worst case is n^2 because you can imagine degenerate sets where the points are already forming their own convex hull. It's definitely a good and simple method and if I was actually going to *program* this it might be where I started. A lot of the time it'll be reasonably perfomant because in a lot of cases "h" is a lot smaller than "n"

On a completely unrelated note, the way I found out about or got into computational geometry is that I was a network administrator for the EE/CS building, and one of the guys I worked with a lot was a PhD student who was working on the "museum guard*" problem. He needed a way to generate polygons that wasn't "biased" in any way, i.e. it needed to generate polygons of all types, i.e. a method that didn't accidentally show bias towards one kind of polygone over another. I don't actually know how hard this problem was but I thought of a solution and I showed him and he convinced me/helped me write a short paper about it. After that I started studying the field and writing more papers in it.

* the museum guard problem is fairly well known so maybe you've heard of it. Basically imagine a museum room that is defined by some polygon. Pick 2 points A and B on the polygon. There are 2 guards, both start at A and walk to B, each along their own side of the polygon. They must stay in line-of-sight of each other the whole way

Pretty much this. I've had interviews where they told me straight out that my minimum expectation is 4 or more years of QA with no advancement.

These questions should be asked up front. A 4 month internship is totally different though.

That?s interesting, I never heard of that.

I?m basically going to create one hull for one set, and test if the points in the other set fall inside the first hull.

I could create two hulls and just test those points, might be faster, idk.

I found a method for testing if a point falls inside of a polygon inside of a 1978 thesis paper, and it is log n. I asked if I could just use this method in my homework and credit the source, and I got kind of a shaky ?yes? from the professor. Not sure what else to do really because there?s no way I could have come up with that algorithm on my own, or if it?s just sufficient to describe my algorithm as ?test if a point falls inside of this hull, which is log n.?

Anyway, thank you, i?ll undoubtedly have more questions and will post in the hw thread from now on, sorry for derail

Yeah, that's what I'd do.

Do you have a link to the paper? I wonder if it's the same method I have in mind.

http://euro.ecom.cmu.edu/people/facu...amosThesis.pdf

Page 92

My first thought for checking "insideness" of a point is to add it to the convex hull calculation. If the hull doesn't change, it is inside.

The question then becomes whether this calculation is O(log(n)). Clearly, recalculating from scratch is O(n log(n)), but we already know the hull. So I suspect the thesis method gives a solution, although I have not read it.

Edit: oh I see, the thesis spells out a o(log(n)) approach.

If you want to do it that way you’d have to reconstruct the hull n times, so i think it’d be n^2 log n unless you used some trickery.

the funny thing about this course is that it does not have a linear algebra or algorithm analysis prereq, but if you had never seen either, I'd imagine you'd be completely ****ed.

i may have mentioned it before but it's a mixed graduate/undergrad course but I looked at the grad homework and they just have 1 additional problem that's not even much harder than the rest.