Moving in IT/Programming

Soldato
Joined
17 Jun 2012
Posts
11,259
So send CV to agency, didn't even realise they did IT jobs, I have done a few jobs and put that I had some programming and other IT skills and she phones me up quite interested in this - hope I didn't overcook the CV.

So have appointment next week and quite interested in getting into development
although I have no idea have far away I would be from professional development, I suppose an interview with an employer would soon sort that out.

I have never hung about with other programmers/IT people, so it's like working in the dark, on one hand I could be at the level of a script kiddie who can hack a
php/perl page together or a simple dialog box in C#, on the other hand I may be up to the task, I started writing a full C++ Lexer/Parser for example, though stopped after about 600 lines as it was becoming to tedious and repetitive.

I could learn plenty of interview questions. I just have never been put to the test and don't have the CS degree either so I am missing a lot of fundamentals such as algorithms, sorting, cryptography, just all the fundamental programming/hardware theory you would learn in a CS degree.

So I feel like I would blag through it, I could just see me blagging into a job then be totally out of my league.

have a look at http://en.wikipedia.org/wiki/Frank_Abagnale

What do you think?
 
This is something which concerns me too. I'm now at a point in my current role where I feel I've gone as far as I can go and since the company don't give the opportunities I'm after for training and personal development, I'm worried about getting over my head if I move.
 
stopped after about 600 lines as it was becoming to tedious and repetitive.

If 600 lines is too much, I don't think you are cut out to be a programmer. I only code because its hard to be a network engineer with some coding skills. Last two projects probably have around 10-20k lines of code each, and these are nothing spectacular.
 
If you have no formal CS training or certification then expect them to ask to see a portfolio of your work.

I started writing a full C++ Lexer/Parser for example, though stopped after about 600 lines as it was becoming to tedious and repetitive.

If you find that tedious and repetitive, then why do you think a programming job is for you?
 
there are developers out there who aren't particularly skilled though a lot of their workload is just writing fixes, maintaining existing code.

I don't see why someone who's been involved in projects in their own time couldn't land a role as a developer - you might well have a better theoretical knowledge than some... what you won't likely have done on your own however is debug, maintain some code someone else has written. Writing your own stuff from scratch is one thing, looking at a big mess of code and trying to fix it is another... if you find a short project tedious then you might well find the average development job tedious - there are plenty of devs out there doing pure grunt work with existing products rather than working on brand new stuff.
 
The answer is: it depends.

If you're applying for a software engineer role at Google, I wouldn't expect you to get too far (or the interview).

If you're applying for a web developer job at a small business that doesn't really understand what they want or need - or how to judge a programmer's skillset - then I'd say your chances of blagging it are excellent.

... I started writing a full C++ Lexer/Parser for example, though stopped after about 600 lines as it was becoming to tedious and repetitive.

Whenever someone tells me the code they're writing is "tedious and repetitive", I assume they're doing it wrong. FWIW.

Most IT companies will have a test as part of the interview process, so chances of blagging it are slim to none.

Unfortunately I've seen "developers" employed despite miserable failures on technical tests. Some IT managers just don't get it.
 
there are developers out there who aren't particularly skilled though a lot of their workload is just writing fixes, maintaining existing code.

I don't see why someone who's been involved in projects in their own time couldn't land a role as a developer - you might well have a better theoretical knowledge than some... what you won't likely have done on your own however is debug, maintain some code someone else has written. Writing your own stuff from scratch is one thing, looking at a big mess of code and trying to fix it is another... if you find a short project tedious then you might well find the average development job tedious - there are plenty of devs out there doing pure grunt work with existing products rather than working on brand new stuff.

I actually have done quite a bit of that, I've ploughed through huge code bases many of times trying to work out what is going on. How about the Nasm source code, the Unreal source, GCC source, many emulators, Qemu source, tons of game engines, Linux drivers etc. But as I said it's hard to gauge the gap between me and a professional developer.

Maybe I should just go freelance or start my own company as most businesses would not have a clue if you wrote hacky code, as long as it works.

The other thing is I know there is a whole techie language as well.

I only meant the parser was tedious as it's just string manipulation, and one function is relatively the same as the next. There's also no need for C++ to write one, should be written in C, I did it to improve my C++ skills but as I said it's a task for C so I wasn't learning anything new.
 
...
Maybe I should just go freelance or start my own company as most businesses would not have a clue if you wrote hacky code, as long as it works.
...

As a software developer myself, I get frustrated and annoyed when people get contracted at some extortionate sum, write rubbish code and then walk away from the project for someone else to have to get contracted in later to fix the mess. I guess that it keeps (good) contractors in business when they have to fix other people's mistakes though. :) I'm reminded of a massive software project that my previous employer contracted to a big Indian offshore company. The company's software developers' idea of inheritance was copy and paste. Thankfully I didn't have to work on that project. I was told that it was an absolute mess. :(

... there are plenty of devs out there doing pure grunt work with existing products rather than working on brand new stuff.

Indeed. One of my experienced software developer friends suggested the idea that software development work is 90% grunt and 10% bleeding edge. Thankfully, I am squarely in the 10%. :D :)
 
Last edited:
... You can't blag a developer technical interview.

... if the interviewers are good at technical interviews. My team has a technical component to our interviews where we set one of several fairly complex programming challenges and assess the proposed solution and reasoning behind it. Some people have failed to progress in the recruitment process just because their answers to that part alone weren't good enough.
 
What kind of developer are they looking?

There are many developer roles that just aren't particularly demanding technically, and require an understanding of the business side much more.

"Professional" covers quite a large spectrum of technical abilities and requirements.
 
The world of professional software development is full of a lot of snobbery, some think everyone has to be an expert/extreme geek from the get go.

Some things that will get you a lot further than you think...personality, social skills, business sense etc. Depends on the company/who is involved in the hiring process of course.
 
What do you think?

Well you may as well try your luck. Assuming you're interviewed by someone technical then I don't think you have a chance of blagging it. If you do mange to "blag" it then you probably are suitable for the role. I'm not sure how common it is to walk into a development role without a degree or a portfolio that demonstrates your skills but I imagine it's rare.

Some things that will get you a lot further than you think...personality, social skills, business sense etc.

Of course those things are important but I don't think they'll make up for a lack of technical knowledge during the hiring process, particularly not in smaller companies.
 
Last edited:
Actually we'd decided to make an offer on a guy I interviewed yesterday. I did about 25 phones interviews, 2 in-person interviews and we picked one guy.

It is surprising how few people can even pass a phone interview. Some of them have shinning CVs full of buzzwords, some of them even have positions on their CV that are rather amazing sometime, and can't even answer simple questions about generic things. And even the guys we interviewed in house are not 'fantastic' either; we decided t hire one because 1) we need someone and 2) we hope he will shape up, his "shape-upability" seems better than the other guy.

Now, on the other hand, I know a few people from "the side", ie IRC, and stuff that are considerably better technically, and some don't beleive they would rate very high on a professional scale.. I've been trying to convince them otherwise...

So my professional opinion is, GO FOR IT. I started programming when I was 12y/o, and I bluffed my way thru the first few jobs. After 30+ years as a developer, I've seen many, MANY people who couldn't lace their own shoes (some of them with a doctorate in CS) and quite frankly, I would talk and hire to any of the "up and comers" who are willing to learn and are 'hungry' for knowledge.

GO FOR IT. The only person stopping you going for it is, you.

Oh, PS: Don't hesitate to say you don't know, but make sure to point out that you want to learn /everything/ and are enthusiastic about it. I would hire one of /these/ any day compared to people trying to drown me in buzzwords.
 
The world of professional software development is full of a lot of snobbery, some think everyone has to be an expert/extreme geek from the get go.

Some things that will get you a lot further than you think...personality, social skills, business sense etc. Depends on the company/who is involved in the hiring process of course.

Those things wont get you that far.
We send out a technical test and only success at that will we arrange a Skype interview with more technical questions. Only once that is passed will we fly someone over for the interview and do more technical and personality tests.


Regardless of someones personality if they don't pass the technical tests then it is likely no one will even speak to the candidate.
 
I personally rarely bother that much on the pure technical; what I ask is more 'open ended' questions that shows pretty quickly if someone knows what they are doing. It's actually fairly easy to do tech questionnaires, that will not prove you can program your way out of a paper bag.

Something like "can you tell me the differences between a cooperative and preemptive scheduler, and what would you consider be the advantages and disadvantages of both"

That sorts out the lamers very, very quickly. Some other, even simpler questions I have turned out to have and even lower response rate.
 
BusError: Jesus, that's an easy question?
To the OP, just go for it. Make sure you've read up on the areas they want you proficient in and try to be yourself.
 
Of course those things are important but I don't think they'll make up for a lack of technical knowledge during the hiring process, particularly not in smaller companies.

I'd be inclined to argue the opposite to be honest, anyone can learn to code, but if you're a social retard who can't communicate with people, that's not really something that can be improved upon easily. Not so much an issue in a big company where you get given your spec and go off to your cubicle to work on it in isolation, far more of an issue in a small company where everyone has to work together more closely
 
BusError: Jesus, that's an easy question?
To the OP, just go for it. Make sure you've read up on the areas they want you proficient in and try to be yourself.

Well, theres quite a few subtleties many people miss. The "of course pre-emptive is better" is a very good discriminant. The right answer is, as in many case "it depends" and explain why.

If someone knows how to reply to that question, the nitty-gritty of the syntax details of language X or Y is a lot less important.

Personally, I'm a frigging expert in C for example, but I could probably still be caught by a few corner case that by experience, I carefully sidestep. So for example:
+ I don't know by heart all the operator precedence in expressions for all operators
+ and I don't know that because I frigging make sure to parenthesis /everything/ since 20 years ago when I accidentally erased the shared memory segments of a mini-computer and annoyed 200 users because I had cut+pasted the wrong 'clever' expression :-)
 
Back
Top Bottom