Jump to content

Recommended Posts

I'm still checking from time to time about Delphi jobs and I have an important message. If you are in leadership at a company that is looking for Delphi developers and you are having difficulty finding them. You need to change your hiring process!!! If your people answer the phone and don't have any idea that your company is hiring or don't know who to connect the caller with to find out if your company is hiring, you will not ever find Delphi developers. If whoever answers the phone sends possible applicants to an HR extension that goes directly to voicemail and no one ever returns the call, you'll never find Delphi developers. If your company is in the US and you hire an outside company to find you Delphi developers, but they can't speak a word of english you are not going to find Delphi developers in the US. If you treat applicants like cattle, by expecting them to just go to your website and fill out your twenty page application without question, you won't find any Delphi developers. If your stupidass application system underlines the word english as if it's not a word, when they whole system is using english you won't find any Delphi developers.

 

Just a few pointers to help companies with their hiring.

  • Like 1

Share this post


Link to post

It's "English", not "english".

Just saying ...

 

Apart from that I agree 100% and I could add some more, but I can't really be bothered.

Share this post


Link to post

Is it just me, or do all job postings look the same these days?

 

I find that one thing missing in most of them is any mention of the application domain or what's involved.

 

Every one says the incumbent candidate will be able to take requirements and fix existing code or write new code.

 

Most Delphi job reqs say something about being able to read and translate Delphi code to C#/.NET but never say they're porting the application.

 

Virtually all of them mention SQL, SQL Server, "modern DB components" and whatnot, but don't usually say if there's a separate team that is responsible for working up ALL SQL queries and stored procs and devs aren't allowed to touch them (which has been the case with the past 5 gigs I've had).

 

Then they lay out some behavioral things that they think apply to a "rock star" and hope applicants meet them.

 

If the ads didn't mention Delphi at the top or say they were looking for programmers, it would be hard to tell other than from buzz words used in the job description.

Share this post


Link to post
3 hours ago, dummzeuch said:

It's "English", not "english".

Just saying ...

 

Apart from that I agree 100% and I could add some more, but I can't really be bothered.

I was hoping to somehow get it to display underlined after I posted But, couldn't.

Share this post


Link to post
3 hours ago, David Schwartz said:

application domain or what's involved

A programmer needs to know those things? 🐵

 

Another good one is when they mention a bunch of Delphi components, but then don't have the word Delphi in the ad.

Edited by Rick_Delphi

Share this post


Link to post
12 hours ago, Rick_Delphi said:

A programmer needs to know those things? 🐵

Definitely! For example I would not enjoy working for some weapons manufacturer. And I have no love for accounting either... I love medical devices, so that's my home. No other job would interest me, no matter what the pay or work environment.

  • Like 1

Share this post


Link to post
4 hours ago, Sherlock said:

I love medical devices, so that's my home. No other job would interest me

Interesting. I would never ever work again for a company involved with medical devices or software. The pseudo QM requirements (not really improving quality but generating lots of paper) drove me crazy.

Share this post


Link to post

Based on my experience, many years back, ISO... quality improvement is just generating piles of paper. The more the better. A manufacturing customer told me: If the worker did everything the way it is required so:
he will do nothing, he will just write something down
I'd be bankrupt in no time. I have a batch of 10 pieces and one is defective. I have to throw away all 10 pieces :classic_ohmy:
Maybe that has changed.

Share this post


Link to post

For fun. Completely off topic. Those ISO were invented so we couldn't compete in the western market. Supposedly. Is that true? The story is real.
Siemens was offering measuring equipment to a chemical company.

Company: we would like to buy it from you, but we can't.
S: gone?
Company: you don't meet the ISO standard
S: they went home and worked hard to meet ISO

Share this post


Link to post
1 hour ago, Stano said:

Based on my experience, many years back, ISO... quality improvement is just generating piles of paper.

For medical devices/software it's not just ISO 9001 (which applies to my current job too) but the even worse standards of the American Food and Drugs Administration (FDA). I spent about 90% of my time producing paper, so our customers had to pay 10 times more.

Share this post


Link to post
2 hours ago, dummzeuch said:

the even worse standards of the American Food and Drugs Administration (FDA). I spent about 90% of my time producing paper, so our customers had to pay 10 times more.

That's the basic function of bureaucracy, to waste everyone's time and money so the people in the bureaucracy can justify their paychecks.

  • Haha 1

Share this post


Link to post

A lot of these things seem to have the net result of converting things back to a centralized administration. The "PC Revolution" decentralized the computing systems and put a PC on everybody's desk. But now there's an IT Dept that manages everything on those computers. Other groups are getting their fingers into the processes they're being used for, including software development, bug tracking, and document production.

 

Software development has lost a lot of what used to make it fun. Agile has been a big contributor to that.

 

CMMI doesn't say what processes to follow, only that an organization needs to lay out some processes and move the organization in a direction that they are always followed, mostly for the purpose of taking individual decision making out of the hands of developers and putting them on some kind of committee or automated process manager. One place I worked was moving towards CMMI Level 3, and part of their process model said that any changes to source code had to be traceable back to a work order or bug ticket, and we couldn't check in any code that didn't have that. Another aspect of their process model said that although the Dev Team owned the Agile ticket backlog, we weren't allowed to put anything into it. In fact, we could not post bug tickets at all -- only the customer can do that, and each bug ticket had to be accompanied by detailed instructions that allowed us to reproduce the errors. Which is fine as long as you don't have bugs in the system that cause random errors that cannot be reproduced because they're data-sensitive; they cannot be touched by anybody for any reason, even if we found and documented some along with how to fix them. (I'm speaking from experience.) It's not as much fun any more.

 

 

Edited by David Schwartz

Share this post


Link to post

Here's the best on yet... You call and the voice message says to send your resume to some email address. Seems like they may be lost in a world all their own.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×